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

10.2.3 NSX–MH 与 OpenStack 的集成

        之前在介绍 NSX-MH 的管理平面时已经讲到，在 NSX-MH 中，各种服务可以被 CMP 进行运维和管理， CMP 是一种云管理的平台，它可以是 OpenStack、 CloudStack 或其他第三方的云管理平台。本节将介绍在 NSX-MH 中， OpenStack 是如何扮演 CMP 角色的。 NSX-MH 与 OpenStack 的集成不需要 VIO 软件，直接将 OpenStack 的 API 与 NSX Manager 的 API 进行互相开放，使得 OpenStack 在成为多虚拟化环境下的自动化管理工具 的同时，成为 NSX-MH 的 CMP。而 NSX 提供的 Neutron Plugin 叫作 NSX Plugin，它允许 OpenStack 使用 NSX-MH 中的所有网络服务。

        NSX Plugin 的集成可以帮助企业 IT 实现向云计算架构的过渡。为此， NSX-MH 向 OpenStack 提供了新的方法来管理逻辑网络的基础架构，旨在提供基于策略集中化的框架， 来提高系统的灵活性、扩展性和本身的性能。此外， NSX-MH 的 API 是开放的，允许新的 （包括第三方公司的）插件融合进 NSX-MH 与 OpenStack 的集成架构中。 在 NSX-MH 与 OpenStack 的集成架构中， OpenStack 的租户可以透明地配置和管理 NSX-MH 提供的逻辑网络。 在租户的界面中进行了配置后，二层交换网络、三层路由、安 全等 OpenStack Neutron 命令会转换为网络配置文件，为租户服务。

         在数据中心网络中使用 NSX-MH 与 OpenStack 集成， 除了可以将管理多租户虚拟化环 境的 OpenStack 和其逻辑网络统一起来之外，还具备如下的优势。  实现易于开发应用的自动化平台：在 NSX 网络虚拟化平台中，应用与策略相关联，策略定义了应用与其他组件（包括外界）通信的方式。这些网络的策略通过 NSX Plugin 转换为 OpenStack 具体的网络需求，开发人员就可以根据互联网络的情形， 按照这些需求在整网中部署应用，最终加快应用的部署， 并确保部署的最终应用 是最适合运行在当前基础网络平台之上的。

         物理和虚拟网络的集成：之前说过， NSX 网络虚拟化平台实现了物理与虚拟网 络的解耦，但是在部分情况下，物理网络与逻辑网络还是需要看成一个整体的， 如数据库服务器使用物理服务器的情形。随着 OpenStack Ironic 项目的持续发 展，也对 OpenStack Neutron 网络提出了更高的要求—透明地涵盖物理网络和 逻辑网络的环境，并将其在管理和可视性上形成一体化。在没有 OpenStack 的 环境下，需要在 NSX 的 API 上进行二次开发来实现，而使用 NSX-MH 与 OpenStack 的集成架构，这一点就比较容易实现了。并且，物理网络和逻辑网络 中的隧道封装，也可以根据 OpenStack 的配置策略自动生成， 而无需逐台地在 物理设备上进行配置。  服务链： NSX-MH 与 OpenStack 的集成架构允许两个终端之间透明地插入和删除 服务，这些服务包括路由、防火墙、负载均衡等。尤其是在多租户环境中，这个 功能显得相当重要。 租户的 IT 管理员可以根据自己的业务特点，借助 OpenStack API 或 NSX-MH 提供的界面，进行服务的定制化配置，尤其是在非 OpenStack 环 境下，配置服务物理终端节点上的服务是 NSX-MH 并不擅长的。

10.3 NSX-V 的 VIO 安装和部署

        本节将在实验环境中演示 VIO 的安装以及与 VMware 的集成。尤其在配置 Neutron 网 络环节，会重点讲解如何通过 NSX-V 进行部署。

10.3.1 安装和部署 VIO Manager

        在通过 VIO 部署 OpenStack 之前，需安装和部署 VIO Manager。步骤如下。 1．需要部署VIO Manager的OVA文件， 如图10.11所示。与部署NSX-V的NSX Manager 类似，找到 vSphere Web Client 的 Deploy OVF Template，开始安装 OVA 文件。之后需要接 受 EULA（最终用户许可协议， End-User License Agreements）。这些都是安装过程中的 Source 部分。

2． 在同意并确认 EULA 之后，开始对导入的 OVA 模板进行初始化配置的工作，这 些都是安装过程中的 Destination 部分。首先为其起名，并选择所在的文件夹， 如图 10.12 所示。

之后选择其存储格式，并指定数据存储位置。实验环境中，我们选择 Thin Provision， 因为它比较节省空间， 如图 10.13 所示。

再为 VIO Manager 选择其所在的网络位置， 如图 10.14 所示。

在图 10.15 所示的用户定制化模板中，需要指定其网络设置，这些网络信息如下所示：
 VIO Manager 的域名；
 VIO Manager 的 IP 地址；
 VIO Manager 的子网掩码；
 VIO Manager 的默认网关；
 VIO Manager 的域名服务器；
 VIO Manager 的域名搜索路径；
 VIO Manager 的 IP 地址；
 VIO Manager 的 URL；
 NTP 服务器；
 Syslog 服务器。
3． 跳过随后的 vService bindings 步骤，检查并完成配置。这时，在 vSphere Web Client 的主界面就可以看到一个 VMware Integrated OpenStack 的 vApp 图标， 如图 10.16 所示。 这里需要注意的是， 可能需要重启一次 vSphere Web Client 才能看到这个图标。

10.3.2 通过 VIO Manager 部署 OpenStack

        VIO Manager 安装完毕、 正常运行且成功注册到 vCenter 后，就可以通过 VIO 来部署 OpenStack 了。在部署中会发现，这样的部署方式比通过传统方式部署 OpenStack 要简易得 多。具体部署的步骤如下。 1．单击 VIO 的图标进入 VIO 系统，在 Getting Started 界面中单击 Deploy OpenStack， 开始部署， 如图 10.17 所示。

2． 随后就会看到一个向导化的配置界面。如图 10.18 所示，首先需要选择部署模式。 可 以选择部署一个新的 OpenStack 实例，也可以通过模板文件来部署 OpenStack 实例。由于之 前并没有部署，也就没有模板，因此选择进行新部署工作。

        在初始化部署过程中需要输入 vCenter 的用户名和密码， 如图 10.19 所示。 然后，还需要选择其部署所在的管理集群位置，如图 10.20 所示。 3．进入基本网络的配置界面。这里配置的是基本网络，而不是通过 NSX-V 部署 Neutron。在这里配置管理网络和外部网络的各种信息， 如图 10.21 所示。

也可以进行负载均衡设置，配置其公共域名和公共的虚拟 IP 地址， 如图 10.22 所示。

4． 现在进入 Nova 的配置阶段。首先增加一个用作 Nova 的计算集群， 如图 20.23所示。
 

然后增加 Nova 数据存储，用来存放不同的实例， 如图 10.24 所示。
5．还需要选择一个数据存储，作为 Glance 镜像服务， 如图 10.25 所示

6． 现在终于到了 Neutron 网络的配置阶段。之前说过，这里可以使用 NSX-V 进行部署，也可以使用 VDS 进行部署。基于本书主题，我们选择 NSX-V 进行部署， 如图 10.26所示。 需要输入以下信息：
 NSX Manager 的 IP 地址；
 NSX Manager 的管理员用户名和密码；
 选择 NSX-V 中用于数据流量传输的传输区域；
 选择 NSX Edge 集群，这是一个部署 NSX Edge 实例的 vSphere 集群；
 选择 NSX 逻辑网络运行的 VDS；
 选择外部网络，这是通过一个虚拟路由器在 OpenStack 的一个实例中作为外部网络的 Port-group（端口组）。这个 Port-group 需要连接到计算、管理和 Edge 集群。

7．通过 NSX-V 配置 Neutron 之后，向导会要求提供 OpenStack 的认证方式， 如图 10.27 所示。可以配置数据级的认证（用户名和密码），也可以通过 AD 或 LDAP 服务器来进行授 权。在实验环境下，选择输入 OpenStack 的管理员用户名和密码。

8．最后指定 Syslog 服务器， 如图 10.28 所示。检查配置并单击 Finish 按钮，通过 VIO部署 OpenStack 的工作就完成了。

9．部署所需的时间取决于系统存储的大小和性能。 在真实生产环境中不建议使用 NFS作为存储系统。全部配置完成之后，就可以在 vSphere Web Client 中看到运行 VIO 的各个组件的虚拟机了， 如图 10.29 所示。

10．在浏览器中通过 HTTPS 的方式，输入 VIO 的域名或地址，就可以通过之前设置的认证方式（用户名/密码或 AD/LDAP）登录 VIO，以进一步管理 OpenStack 了， 如图 10.30所示。

登录后的界面如图 10.31 所示。 可以看到其界面和我们熟悉的 OpenStack Horizon 界面 非常像，在配置和管理计算、网络、存储等的操作上也是一致的（只是多了一个 VMware 的 Logo）。之后就可以方便地通过 VIO 界面配置 OpenStack，同样可以通过标准的 OpenStack API 来使用 OpenStack 的服务。有关之后的操作，有兴趣的读者可以参考专门讲解 OpenStack 的书籍。

10.4 总结

         OpenStack 是当前流行的数据中心自动化管理软件，其诞生仅 5 年多时间， 但是发 展势头极其迅猛。  在网络方面， OpenStack 提供的组件叫 Neutron，它为 OpenStack 提供了网络即服 务的接口。  VMware 与 OpenStack 的关系不是竞争，而是合作。为了集成 OpenStack， VMware 推出了 VMware Integrated OpenStack（VIO）发行版软件，使得 IT 管理员可以快 速部署 OpenStack，而使用 OpenStack 时，也能用到 vSphere 的各种高级特性。  VIO 最新版本是 2.0，它基于 OpenStack 的 Kilo 版本。  可以使用 VDS 来部署 VIO 的 Neutron 网络， 但更推荐使用 NSX-V。使用 NSX-V 部署 VIO 的 Neutron 网络能给用户带来更多的功能和更好的体验。  在 NSX-MH 环境下，可以使用 NSX Plugin 的方式将 NSX 与 Neutron 集成。

第11章 在 NSX 之上集成第三方服务

        尽管 NSX 能实现强大的功能，但是如果企业已经使用了其他专业的安全或应用交付厂 商的设备或服务，并且已经有了使用习惯和良好的体验， VMware 仍然可以通过在 NSX 之 上集成第三方服务的方式，让专业的网络安全厂商、专业的应用交付厂商来进行处理。 NSX 的生态系统包括了大量的厂商，我们无法将这些厂商与 NSX 融合的解决方案一 一罗列。

        因此，本章主要就 NSX 的应用层防火墙、防病毒、应用交付这三个可以在 NSX 网络虚拟化平台之上集成的重要功能入手， 列举几个最典型的融合解决方案，来介绍如何 在 NSX 之上集成第三方服务。 此外， VMware 正在与国内安全和应用交付厂商进行合作，希望将这些国内厂商的解 决方案集成进 NSX 网络虚拟化平台，共同打造适用于中国国内企业的安全和应用交付平 台。 VMware 的研发人员正在与这些厂商的研发人员共同进行开发，相信不久的将来会有 更多的解决方案供不同企业选择。

11.1 NSX 与合作伙伴打造下一代数据中心安全

        之前在介绍 NSX 安全时已经提到过， NSX 与第三方安全服务的集成，主要是通过“嵌 入、链接与定向” 的服务模式来实现。通过将流量重定向到第三方安全厂商的服务中，选 定一个第三方安全服务并将其集成到 NSX 网络虚拟化平台。例如，来自互联网的一个 Web 流量，需要去往内部 Apache 或 Tomcat 服务器，就可以将其重定向到 5-7 层的第三方深度 包检查防火墙服务中，以实现高级安全防护。 在 NSX-V 6.0 版本中，这种流量重定向是在 Service Composer–> Security Policy 菜单中 定义的。而在 NSX-V 6.1 版本之后，则提供了专门的第三方合作伙伴的界面， 可以在 Partner Security Services 下的分布式防火墙菜单中，定义流量重定向的策略。

        Partner Security Services 提供了一个强大且易于操作的用户界面来定义什么类型的流量需要被重定向到该第三方安全服务。它遵循与分布式逻辑防火墙相同的策略定义结构， 即源、目的和服务类型的结构，它们唯一的区别在于执行上—第三方安全服务不执行 Block/Allow/Reject 的操作，而是选择重定向/不重定向（Redirect/No Redirect）； 一旦选择重 定向，就会由第三方安全内部进行真正的策略执行操作。 本节会介绍 NSX 最重要的安全合作伙伴 Palo Alto 公司的产品是如何与 NSX 网络虚拟 化平台进行集成并提出融合解决方案的。之后会简单讲解 NSX 与其他几个安全合作伙伴的 集成解决方案。

11.1.1 Palo Alto NGFW 解决方案

        近年，由于用户使用应用程序的行为和网络基础架构发生了很大改变，安全威胁进一 步提升，传统的基于端口策略的防火墙的一些弊端也日渐暴露。用户现在会使用各种设备 访问更广泛的应用，这样的行为会带来业务安全的风险。同时，数据中心扩展、服务器虚 拟化、网络虚拟化和移动接入的蓬勃发展，迫使企业需要重新思考访问应用程序和数据 的方式，从而保护网络免受一些攻击方式更先进的新威胁。这些内容在第 6 章已经阐述 了很多。

         Palo Alto 公司推出下一代防火墙（NGFW）的目的，是让企业实现应用安全的同时， 防范已知和未知的威胁。 Palo Alto 企业安全平台使用积极的安全控制模型，这个模型的特 点如下。  基于应用层特征而不是端口识别应用：现今， 在访问应用时很容易使用各种技术 绕过一个基于端口的防火墙，这样就带来了应用安全隐患。而 Palo Alto 企业安全 平台通过独有的 App-ID（应用识别）技术，将多重分类机制应用在了流量中，使 得平台对原本能见度有限的流量有了很高的可视性，以确保穿越防火墙的是被允 许的应用流量。 而且在识别所有流量时，都不关心其经过的端口和加密方式（ 如 SSH 或 SSL）。

         减少威胁痕迹以阻止已知安全：一旦应用识别完成，企业就可以通过只允许与企 业业务相关的应用需求访问网络，并且对其内容进行检测的方式，来保护它们的系统 免遭各种类型的攻击。入侵防御系统（Intrusion Prevention System， IPS）模块可以防 范网络层和应用层的攻击、 缓存溢出、 DDoS 攻击和端口扫描。防病毒/反间谍软件模 块可以防范数以百万计的恶意软件变种，这些恶意软件变种包括隐藏在压缩文件、 Web 流量（使用 HTTP/HTTPS 压缩）、 PDF 文件中的病毒。而 URL 过滤模块可实现 对恶意站点的过滤，并对试图解析恶意域名的内部主机进行标识。对于使用 SSL 进行 加密的流量，则可以选择基于策略的解密功能对其进行检测，而不关心其端口。 Palo Alto 将入侵检测、防病毒和防间谍软件模块组合在一起，定义为威胁防御功能，并不是简单地拦截恶意内容，而是在其上增加了具体的策略控制，以及为具体的内容进行 深度检测，防止完全拦截而造成的数据丢失。

         防范未知威胁：一些未知的攻击，如定制或多形态的恶意软件，正越来越多地 出现在现代网络中。 Palo Alto 将其 NGFW 通过 WildFire 服务提供的高级检测和 分析功能进行扩展。 WildFire 服务提供了一个在线的云沙箱环境， 可以模拟运 行预先定义的可疑文件，并通过行为分析的方式判断文件的安全性，从而在设 备自身的签名无法检测到威胁的情况下，对可疑文件进行进一步分析，发现并 防范未知威胁。 Palo Alto 在防范未知攻击方面有如下高级功能。 这些高级功能 增强了在攻击生命周期每个阶段中检测未知威胁的能力，可极大地降低入侵企 业且需要人工参与事件响应的威胁数量。如果威胁仍得以入侵，企业和事件响 应团队也可以通过可视化视图获取相关数据，并快速采取行动。  文件可见性得以扩展：现在可查看和筛选的常见文件类型包括 PDF、 Office 文 档、 Java、 APK、 DLL 和 EXE 文件（无论是否加密）。  零天攻击检测：在 WildFire 云中通过使用针对特征的行为分析，快速识别常用 应用程序和操作系统中的攻击，并在 5 分钟内将分析情报和针对威胁的全新签 名发送给订购其服务的客户， 以阻止未知攻击。  发现恶意域名：通过构建遭到入侵的域名和基础结构的全局数据库，在攻击正 使用关键的命令或处于控制阶段时阻止攻击。

         事件响应数据的单一界面视图：在单一视图中，安全管理员可访问有关恶意软 件、恶意软件行为、遭到入侵的主机等丰富信息，便于事件响应团队快速识别 威胁并构建主动控制。 传统 UTM（Unified Threat Management，俗称安全网关） 和 Palo Alto 的 NGFW 最根本的 区别在于它们解决问题的方式。 UTM 将已有的网络安全功能固化到一个盒子中，例如状态检 测防火墙、 IPS、 AV、 URL 地址过滤，其本质是在状态检测防火墙上添加多项安全功能，从而 让网络更安全。而 Palo Alto 的 NGFW 的不同之处是在于，它并没有将很多网络安全功能集成 到一个盒子中，而是重新定义了防火墙的核心特性。市面上所有 UTM 中的防火墙功能都是基 于状态检测的，而状态检测是CheckPoint公司在20世纪90年代早期发明的， Palo Alto的NGFW 的核心不是状态检测，而是基于 App-ID，通过应用识别和用户识别取代以前的通过端口和 IP 地址的识别，从而进行访问控制。