抱歉，这篇文章拖了太久，原来计划这篇写 NSX 与 vRA 集成实现安全随业务自动置备，但一直没能自己搭一个环境去做一些技术的验证，后来发现 VMware NSX 以及 CMP 这块一直在变化，觉得原来了解的关于自动化的东西似乎不是那么重要，也称不上一个场景，于是就一直搁置了。
今天，想把话题改为云安全，讲一下目前 NSX 与云安全相关的话题，文章中也会包括以前规划的 vRA 的部分。
文章较长，下面是大纲，可以按需阅读：
一、关于云计算
前段时间，有个公众号连续发了几篇关于 Openstack 的文章，有褒有贬，夸奖的部分觉得，Openstack 开源、开放、灵活、低成本，在某些场景下可以大量节省成本提高效率；批评的部分则表示，入不敷出、研发热度下降、未跟上时代潮流、技术问题等等。
我对 Openstack 的认识只是通过新闻，几年前，还在想是不是得学学 Openstack，顺应下发展趋势，几年后，很庆幸自己没学，还是专注在商业化产品。
云计算这个词出现已经超过 10 年，对于这个词的理解有很多，关于这个词的滥用也很多，大家最认可的定义是：云计算是一种服务模式，能够通过网络将计算资源或者更高阶的服务按需快速提供给用户。
云计算有两大优势：提升效率、节省成本。
那怎样才能做到这两点？
举个例子，一个企业想要拥有自己的邮箱，可以选择 DIY、也可以选择阿里云等提供商的现成服务，下面是两种搭建方式的对比：
以上表格便可以体现出云计算的两大优势：
- 效率方面：DIY 需要关心非常多的小细节，做很多设计、采购、安装实施，而云服务只需要通过网络去申请，很短时间内便可以使用；
- 成本方面：DIY 需要采购很多设备、软件、运维服务，而使用云服务则可以按需付费，势必 DIY 成本会很高。
如果从底层看，阿里云并不是不需要 DIY 的那些软硬件，而是这部分对最终用户不可见，阿里云所做的，就是将很多资源进行了“包装”，包装成一个个服务提供给客户，客户可以按照自己需要去使用这些服务。
云计算（或阿里云）有哪些关键词？
大量计算资源：阿里云会为很多用户去提供服务，后端需要大量服务器的支撑；
网络：通过网络将大量的服务器连接起来，通过网络将服务提供给最终用户；
量化：需要通过一些手段将服务器的硬件资源进行池化，且能切分成很多小的单元，最终以可计量的形式交付；
界面：一个交付服务的界面，通过这个界面用户可以自己去申请服务，申请完成后，通过后端的自动化程序完成服务置备，置备完成后用户使用这个界面管理购买的服务；
服务：单独的硬件资源池化后，可以直接交付给客户，这样的服务叫基础架构即服务（Infrastructure as a service），或者像上述的举例，在计算资源之上部署一套邮箱软件，然后将软件的功能作为服务交付给客户，这叫软件即服务（Software as a service）；
用户：服务的使用对象，提供的服务必须能够解决用户的某些需求。
二、云计算与虚拟化
前面提到，云计算这个词会被滥用，而有一种说法便是：虚拟化=云计算。
如果按照云计算的关键词，会发现虚拟化可以包含于云计算：
- 虚拟化可以将大量硬件服务器虚拟化，做成虚拟资源池，且这个池原生就可被切分，可被计量；
- 虚拟化提供大规模物理服务器管理能力，可以方便地对上千台服务器做升级维护，能够提供接口让其他软件对接，完成高级的服务定制；
- 虚拟化提供的虚拟机本身可以作为服务提供给用户，在虚拟机上也可以部署软件来提供 SaaS；
- 虚拟化自带冗余能力，可以避免硬件故障带来的服务中断；
- 虚拟化一般具备专业的运维工具，可以保证底层基础架构正常工作，保证上层业务健康；
如果对比云计算的定义，会发现虚拟化距离云计算只差服务的封装和界面，这些功能就是由云计算管理平台去提供的。
三、公有云与私有云
那么对于企业来说，使用云计算有意义吗？
这时候需要提及一下云计算的多种形式：公有云、私有云，以及两者的结合，混合云。
公有云：前面提到的阿里云便属于公有云，通常公有云的所有底层资源都由服务提供商提供，且一套资源可能给多个不同的企业（租户）去使用；
私有云：企业自己拥有数据中心，自己进行服务的定义、供给，企业内部自己使用服务。
公有云和私有云最大的区别便是：资源的拥有者不一样，服务的提供商不一样
而与这两个区别相关的重要区别有：成本、安全、管理及运维方式
成本在这里不多提，公有云采用按量付费的方式，而私有云是一次性硬件投入+日常使用开销的总和，面对不同的场景可能公有云更省钱，也可能私有云更省钱。
安全性上会有比较大的差别：
公有云因为其特殊的属性，能够提供的服务都是标准化的模块，很难个性化定制，更不可能让客户自行部署安全设备，在这个层面上，公有云可能无法满足企业对于安全的合规要求；
私有云的各种服务由客户自行制定，在构建基础资源层时，也可以任意配置安全设备来满足安全合规的要求。
管理和运维上的差异是最大的：
使用公有云时，企业 IT 部门无需关心云计算基础架构的运维和安全，这些全部由公有云提供商提供，唯一需要担心的可能只是业务运行状况，以及数据安全。但考虑到监控和数据安全，采用公有云时面临的又是工具的变更，因为很可能原来本地数据中心的运维、备份系统无法在公有云去使用，需要为公有云定制一套运维工具，新采购一套备份系统。
如果做私有云，则更多的是在虚拟化的基础之上做一些标准化、服务封装等的工作，底层环境完全可以根据以往的经验来构建，运维团队也可以是同样的人，只是需要多学习一些跨域的知识，运维工具也可以保持不变。
理解了上面的内容后，再来看云计算对企业是否有意义。
这个问题不会有标准的答案，原因在于需求不一致时，适合的方案也就不同，举两个场景：
场景1
客户属性：互联网初创公司
人数 ：50 人，但在快速增加
业务：自研的线上业务，总服务器需求 20 台，未来视业务情况可能扩展
场景2
客户属性：某大型代工厂
人数：1000
业务：工控、ERP、Mail 等，总服务器需求 100 台，视项目可能需要增加服务器
对比两个场景，场景 1 更加适合使用公有云，公司规模并不确定，使用公有云可以快速满足业务的资源需求，公司规模较小，如果自建数据中心需要投入人力、空间等资源，总成本会很高；场景 2 则更加适用私有云，公司规模很大，相对稳定，服务器众多，有专业的运维团队，未来会有一些业务扩展的需求，构建私有云可以加快新业务上线的速度，也可以做到新上线业务的标准化。
区分了共有云和私有云，再详细讲讲私有云。
四、私有云的价值
前面泛泛的提到很多概念，相信你已经听晕，或许你只想知道一件事：我需不需要将虚拟化改造为私有云？
这个问题其实可以简化为：云管理平台能干什么？
以下是 VMware 云管理平台 vRealize Automation 的一些功能，按号就座即可：
1、服务蓝图设计：服务蓝图是云管理平台很重要的一个功能，它能将原来裸的 CPU、内存、存储、网络等资源封装成可以直接使用的服务，例如 Web Server服务、数据库服务、备份服务等。
*下图是一个 vRA 部署 WordPress 服务的蓝图，在蓝图中我们可以将操作系统（含存储、计算配置）、软件组件、软件配置、网络配置等编排到一起，组合成一个大的服务。
蓝图设计看似挺简单，但能给企业带来很大的价值：加速业务上线时间，保证标准化，方便运维。
业务上线通常需要经过一系列步骤，而如果使用传统手工置备，则每个步骤可能由不同人来执行，交付一个新虚拟机可能需要几天的时间；每个步骤都由人来执行，如果没有很详细的操作文档，很难保证配置一致性，人工配置也很容易出错。
而如果将以上操作全部做成标准的流程，然后使用机器自动化执行，则能极大加快业务上线速度，减少人工配置失误，保证新创建业务的标准化，一切标准化之后，也可以使用一些自动化运维工具来减少人肉运维。
2、服务目录及自助服务：服务目录是直接提供给最终用户的交互界面，在这个界面中，用户可以查看与自己相关的服务，点击 Request 请求服务。操作很类似于应用商店，非常简便。
3、多级审批及最小权限管理：在传统资源的置备中一般会有很多审批流程，只是传统更多依赖于纸质审批或者 ERP，但是无论哪种流程审批，审批的资源始终是与审批流程独立的，很难以业务为中心做审计、运维，使用云管理平台后，审批过程直接与申请的资源相关，伴随整个业务生命周期。
vRA 使用了“最小权限原则”给用户赋权，可以从根本上避免越权的非法操作，保证整个系统的安全。
4、多租户支持：vRealize Automation 原生支持多租户，允许在一套硬件资源上创建多个相互隔离的租户，每个租户可以根据需求创建自己的蓝图、服务目录、审批流程等。对于企业 IT 部门而言，通过 vRA 可以轻松实现运维角色到运营角色的转变。
5、支持网络自动化：vRA 支持与 NSX 集成来实现网络的自动化置备。
在一个业务上线过程中，网络及安全配置是必不少的一步，而在传统的 IT 架构下，网络、安全及系统管理员通常是分离的多个部门，跨部门协作会极大降低工作效率，vRA 与 NSX 集成后，管理员可以将网络配置及安全配置预先定义在蓝图中，按需自动提供给最终用户。
6、支持策略驱动的存储（vSAN）：在提及策略驱动的存储之前，推荐大家读读”一篇 vSAN 入门，送给大家“，文中提到分布式存储很重要的一项功能“区分服务”，对于上层业务人员而言，每个业务都会有重要级别的划分，比如：重要业务>普通业务>测试环境，三者对于服务等级需求也不同，对应到底层基础架构，需要提供的计算存储资源也是不一致的：
为了保证上述的服务级别，后端的资源池必须能够按需提供不同的资源，对于存储而言，最佳解决方案就是“策略驱动的存储”，这样的存储可以按需快速置备，使用方便，容易管理。
7、生命周期管理：在 vRA 中创建的每个业务都会有其租期，vRA 能够保证每个业务到期后都可以自动回收资源。
8、支持混合云架构：vRA 除了支持 vSphere 环境外，也支持 AWS、Azure 等公有云，在一个蓝图中可以同时调用 vSphere 资源及公有云资源，打造一个混合的服务蓝图。
9、成本分析及计量计费：vRA 与 vRealize Bussiness 集成后可以实现类似于公有云的计费功能，能够直观展示不同业务组的资源用量、花费等信息。
以上便是 vRA 的一些核心功能，但要真正让虚拟化平台变为服务提供平台，还缺少服务状态监控，这部分便是由** vRealize Operations **来完成的。vRops 支持监控虚拟化基础架构、操作系统、应用等，能通过多种监控数据分析业务运行状况，确保其满足服务等级要求。
五、私有云的安全自动化
既然私有云=虚拟化+云管理平台，那私有云的安全其实也就=虚拟化的安全+安全与云管理平台的集成。
虚拟化的安全前面很多文章都有提及，感兴趣的可以查看历史文章，这里着重讲讲 vRealize Automation 如何与 NSX 集成实现安全的自动化。
在前面我们提到，vRA 与 NSX 集成后，可以在 vRA 中将网络及安全的配置加入蓝图中，进而实现网络及安全随业务按需置备，在操作层面有四种实现方式：
**
*在阅读下列部分前强烈建议先读 NSX从入门到精通(7)：NSX 微分段架构、组件及实践 Part2
1、已有安全组（Existing Security Groups）
管理员预先创建好安全组，在 NSX DFW 中预先设定好与此安全组相关的防火墙规则，新增的虚拟机会自动加入已有安全组，自动继承安全规则。在虚拟机被删除后，相关对象也会从安全组中被移除。
在 vRA 中，已有安全组与 vRA 的关联可以在以下两个位置设定：服务蓝图及资源预留中。
*在蓝图中关联安全组
*在资源预留中关联安全组
2、已有安全标记（Existing Security Tags）
**在业务被 vRA 创建时，会自动关联预先配置好的安全标记，此安全标记可以被第三方安全产品识别并对虚拟机进行安全防护，也可以通过标记建立 NSX 动态安全组，使用此动态安全组创建防火墙规则。
3、按需安全组（On-Demand Security Groups）
在业务被 vRA 创建时，自动创建相应的安全组，并将虚拟机加入新建的安全组，需要预先为按需安全组指定安全策略。按需安全组会随着业务的生命周期进行创建和销毁。
按需安全组只能在蓝图中进行配置：
4、应用隔离（App Isolation）
应用隔离通常用于隔离任意两个不同的部署，开启应用隔离后，所有进出此部署的流量都会被禁止，只允许内部虚拟机之间互访。
如下图所示，如果开启了应用隔离，两个使用相同蓝图创建的应用之间是不能互访的，而在内部不同层的虚拟机之间可以访问。
应用隔离是在新建每个蓝图时开启的：
开启应用隔离后，每一次部署 NSX 会自动创建相应的安全组，然后为其分配一个安全策略，允许组内虚拟机的互访，禁止其他访问：
六、VMware 的混合云战略
在 2017 年的时候，VMware 与 AWS 共同发布了 VMware Cloud on AWS，简称 VMC on AWS。
下图是 VMC on AWS 的架构图，VMC 更像是一朵承上启下的云，它将 AWS 的硬件资源与 VMware 的 vSphere 软件平台集成起来，服务由 VMware 提供，资源由 AWS 提供。
VMC 有三大使用场景：
- 跨地域扩展：
假如企业要在一个新的地区扩展业务，通常也会对 IT 资源进行扩容，而在新地区完整搭建一个 DC 成本会非常高，使用公有云服务可以减少开支；
或者客户需要一个完整的异地容灾方案，使用按需付费的公有云可以节省大量成本。
- 资源整合，到公有云的迁移：
此种场景下客户希望逐渐将私有云转移到公有云，如果使用传统的手段将 vSphere 环境的虚拟机迁移到 AWS/Azure 等平台，只能重新搭建应用或者冷迁移，在 VMC 的架构下，vSphere 到 VMC 的迁移可以像本地 vMotion 一样方便简单。
- 按需灵活置备：
公有云有一个很大的特征是按需置备，按量付费，对于一个短期的项目来说，按量付费的方式通常比购买固定资产更加节省资金。
传统的公有云通常能提供虚拟机、对象存储、数据库等服务，而 VMC 提供的是更底层的资源：配置好的 ESXi 主机、完整的 vCenter 管理平台、vSAN 存储、NSX 网络虚拟化、SRM 等解决方案。
相较于传统的公有云，VMC 最大的优势便是底层基于 vSphere，可以更好地和客户已有数据中心结合：
- 用户可以将本地的 vCenter 与 VMC 的 vCenter 通过“混合链接模式 Hybrid Linked mode” 链接起来，实现混合云的单点登录（SSO）；多个数据中心可以使用统一的界面进行管理；支持远距离 vMotion、Per-VM EVC 等功能；如果搭配 NSX Hybrid Connect（详见HOL 更新，NSX 部分有重大变化）或 NSX（L2VPN 及跨云安全服务），可以真正实现在线上云或者下云。
-
管理 VMC 与管理传统 vSphere 差别不大，因此企业 IT 运维人员无需学习太多新知识，直接可以上手操作，传统 vSphere 的运维工具在 VMC 上依然可以使用，例如 vRealize Operations、PowerCLI、vSphere API 等。
-
-
VMC 提供了 Site Recovery 容灾服务，用于构建本地 DC<–>VMC、VMC<–>VMC 这样的双向容灾架构。传统 SRM 的 DR 演练功能在 VMC 中也受支持，允许用户在不影响业务的隔离环境中进行 DR 演练（更多内容见 HOL 1987-01）。
-
-
-
-
为了简化网络管理，VMC 可以和本地数据中心通过一套 NSX 环境管理，并且开发了一个简单的界面，让不懂网络的人快速配置站点间的网络和安全（只需要选中站点间的连线，选择创建 VPN、防火墙规则即可）。
-
-
VMC 也支持 vRealize Automation，创建跨云的混合蓝图。
-
对于 vRA 而言，VMC 就是一个 vCenter Endpoint，操作上和本地vCenter Endpoint 无任何区别。
除了上述常用功能，VMC 还有些“云定制”功能：
- 前面提到 VMC 能够提供很基础的资源：主机，按照云的按需置备特性，VMC 也支持集群的横向扩展，即可以按需扩大集群中主机数量。
-
vSphere 中有一个很好用的功能 DRS，可以自动迁移工作负载，让集群中的主机利用率保持平衡，VMC 中新增了一个功能 Elastic DRS，可以在集群资源不够用的情况下自动添加主机。
-
如果客户同时使用 VMC 和 AWS 原生服务，传统架构下两个云服务必须通过 VPN 才能互联，VMware 与 AWS 共同创建了 ENI（Elastic Network Interface），ENI 相当于 VMC 和 AWS 之间的一个虚拟专线，提供高速的东西向通信网络。
七、混合云的安全
通过上面一大堆的讲解，相信你已经猜到了答案，混合云的安全就是由 NSX 去做的。
不过并不是我们前面文章讲的那个 NSX（NSX-V），而是 NSX-T，以前发的“这篇文章”中有讲过。
NSX-V 虽然好用，但是与 vCenter 强关联，在混合云这样复杂的架构下，为了统一管理只能将网络和安全作为一个平台独立出来，其他所有需要网络和安全服务的组件都这个平台连接，所有第三方的网络安全产品也可以集成在这个平台，为多种复杂的环境提供高级安全服务，这便是 NSX-T 的架构。
虽说 NSX-T 的未来好于 NSX-V，不过目前市场还是以 -V 为主，-T 与 -V 很多理念、工作原理都是相通的，因此还得继续学习好 NSX-V，待 -T 市场成熟了，转变过来也很容易。
“全文完”