VMWare-智能自动化-全-

VMWare 智能自动化（全）

原文：annas-archive.org/md5/f4768b1d7cf739adf5abb42900a03c6d

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

本书从入门的角度介绍了机器学*（ML）在 VMware 环境中扮演的重要角色。它提供了如何利用机器学*原语的基本理解，并深入探讨了与今天用于自动化目的的 VMware 工具的集成。

本书面向的对象

本书面向计划、设计和实施软件定义数据中心基础架构虚拟化/云组件的人员。它帮助用户将智能融入自动化任务，以实现自动驾驶数据中心。假设读者对虚拟化概念和相关主题（包括存储、安全和网络）有所了解，并对这些主题有一定的熟悉度。

本书涵盖的内容

第一章，使用 vSphere 6.7 的机器学*功能，涵盖了在 vSphere 环境中使用 GPU 对基于机器学*的应用程序进行性能基准测试，以支持不同的客户业务目标。

第二章，使用 vSAN 高级分析进行主动措施，解释了如何通过 vSAN 支持洞察高级分析中的主动遥测功能来快速解决问题并最小化停机时间，从而提高对 HCI 环境的支持体验，这将帮助客户通过快速解决问题来维持性能。

第三章，使用 Workspace ONE Intelligence 的安全性，描述了一种针对员工、应用程序、端点和网络的创新企业安全方法，包括访问管理、设备和应用程序管理，以及用于可信分析框架的方法。

第四章，使用 VMware vRealize Suite 的主动操作，解释了如何通过将高级分析注入其 VMware vRealize Suite 来自动化运行在 vSphere 上的数据中心和公共云。

第五章，使用 AppDefense 的基于意图的清单，解释了如何学*使用机器学*为在虚拟机中运行的应用程序创建基于意图的清单，以便通过一个算法来保护应用程序免受恶意行为的影响，该算法通过比较运行状态和预期状态来衡量。

第六章，基于机器学*的智能日志管理，涵盖了如何进行创新索引和基于机器学*的智能分组，以便通过辅助快速故障分析来促进在物理、虚拟和云环境中进行高性能搜索，以实现更快的故障排除。

第七章，《云中的机器学*作为服务》，解释了如何通过定制硬件和软件来构建和维护每个机器学*流程，通过自动化硬件资源的部署、配置所需的操作系统和应用程序堆栈，并使它们对数据科学家可用来消除这种复杂性。

第八章，《基于 Skyline 的机器学*规则引擎》，描述了如何从客户那里收集信息，并使用机器学*作为智能规则引擎来监控是否存在任何超出正常行为的情况，然后发出红旗以提供主动支持。

第九章，《使用 vRealize Code Stream 进行 DevOps》，探讨了最高优先级的流程，以应用技术来比较和对比传统运营模式、流程和团队结构与 DevOps 所需战略运营模式之间的关键差异。

第十章，《利用机器学*转型 VMware IT 运营》，涵盖了 IT 团队在这个变化环境中面临的运营挑战，以及他们如何解决这些挑战以满足客户需求，并具备必要的灵活性和可扩展性来支持快速的业务创新和增长。

第十一章，《利用物联网进行网络转型》，描述了如何通过将安全嵌入到架构中，并从数据中心到云再到边缘管理数据分布，将数据应用跨越区域边界，从医院的监护仪到城市的联网汽车，以及农村地区的风力涡轮机。

第十二章，《在 vSphere 上虚拟化大数据》，解释了如何通过评估当前的内存大数据平台并了解这些平台与具有内存功能的虚拟化如何结合来利用现代大数据平台中的共享存储。

第十三章，《云应用扩展》，描述了如何通过为开发者提供访问传统、云原生和现代应用程序开发框架和资源，包括容器服务和通用虚拟化环境上的开放 API，来支持云应用开发。

第十四章，《高性能计算》，探讨了 VMware vSphere 提供的学*能力，通过 SR-IOV、RDMA 和 vGPU 等特性来提高科学生产力，并构建和满足研究计算、学术、科学和工程工作负载的要求。

为了充分利用这本书

重要的是要关注识别与构建完整的自动化引擎相关的利益、复杂性、风险和相关成本，从数据中心到最终用户设备，以及应用程序。

为了实现这一点，我们将涵盖一系列主题，从高级 GPU 配置及其与在始终可靠的 vSphere 平台上运行的 HPC 和大数据工作负载的性能比较开始，这将帮助您充分利用本书。

下载彩色图像

我们还提供了一份包含本书中使用的截图/图表彩色图像的 PDF 文件。您可以从这里下载：www.packtpub.com/sites/default/files/downloads/9781789802160_ColorImages.pdf。

使用的约定

本书使用了多种文本约定。

CodeInText: 表示文本中的代码单词、数据库表名、文件夹名、文件名、文件扩展名、路径名、虚拟 URL、用户输入和 Twitter 昵称。以下是一个示例：“如果我们不能使用 wget 连接，请下载 .rpm。”

任何命令行输入或输出都按以下方式编写：

# cd /opt/serengeti/www/yum/repos/centos/6/base/RPMS/
wget http://mirror.centos.org/centos/6/os/x86_64/Packages/mailx-12.4-7.el6.x86_64.rpm

粗体: 表示新术语、重要单词或屏幕上看到的单词。例如，菜单或对话框中的单词在文本中显示如下。以下是一个示例：“我们必须选择 Install 单选按钮，并使用 vCenter 信息填写表格，然后点击 Submit。”

警告或重要提示如下所示。

小贴士和技巧如下所示。

联系我们

我们欢迎读者的反馈。

一般反馈: 如果您对本书的任何方面有疑问，请在邮件主题中提及书名，并通过customercare@packtpub.com给我们发送邮件。

勘误: 尽管我们已经尽一切努力确保内容的准确性，但错误仍然可能发生。如果您在这本书中发现了错误，我们将不胜感激，如果您能向我们报告这一点。请访问www.packt.com/submit-errata，选择您的书籍，点击勘误提交表单链接，并输入详细信息。

盗版: 如果你在互联网上以任何形式遇到我们作品的非法副本，如果你能提供位置地址或网站名称，我们将不胜感激。请通过copyright@packt.com与我们联系，并提供材料的链接。

如果您有兴趣成为作者: 如果您在某个主题上具有专业知识，并且您有兴趣撰写或为书籍做出贡献，请访问authors.packtpub.com。

评论

请留下评论。一旦您阅读并使用过这本书，为何不在您购买它的网站上留下评论？潜在读者可以查看并使用您的客观意见来做出购买决定，Packt 公司可以了解您对我们产品的看法，我们的作者也可以看到他们对书籍的反馈。谢谢！

如需了解 Packt 的更多信息，请访问 packt.com.

第一部分：使用机器学*技术的 VMware 方法

在本节中，我们将了解 VMware 如何通过新兴技术，如机器学*，来解决与其员工、客户和合作伙伴相关的业务问题，以创造新的、由智能驱动的最终用户体验，从而加速生产力和响应速度，通过数字化转型实现真正的商业价值。读者将学*如何将 VMware 解决方案中集成的机器学*技术应用于数据中心运营。

本节包含以下章节：

• 第一章，使用 vSphere 6.7 的机器学*功能

• 第二章，使用 vSAN 高级分析进行主动式措施

• 第三章，使用 Workspace One 智能化的安全性

• 第四章，使用 VMware vRealize Suite 进行主动式操作

• 第五章，使用 AppDefense 的基于意图的清单

第一章：vSphere 6.7 的机器学*能力

本书将简要介绍不同的 VMware 工具如何帮助客户获得智能自动检测和预测的好处。这一服务将使他们能够检测、可视化和排除异常、未来需求以及潜在的现代应用程序和基础设施问题——所有这些都不需要用户具备统计或算法专长。VMware 为用户提供对所有服务的健康和典型行为指标的统一可见性，无需用户协助，从而减少了故障排除时间。这些工具还将帮助预测，以了解未来的容量需求，并有效地最大化应用程序和基础设施效率。

本章简要介绍了如何通过使用不同的模式在 vSphere 环境中虚拟化 GPU，为特定用户群体创建配置文件，以及关于不同NVIDIA 显卡及其使用的信息。我们还将了解如何配置 vSphere 中的 NVIDIA GPU 以支持基于机器学*（ML）的工作负载，具有不同的用例，以实现特定的商业目标，同时降低成本。

本章我们将涵盖以下主题：

• ML 与 VMware

• 不同使用 GPU 的模式

• 基于 NVIDIA GPU 的 ML

技术要求

您可以下载以下内容：

• VMware vSphere 6.7

• VMware vCenter Server 6.5 U1

• VMware Horizon 7

ML 与 VMware

VMware 在其大多数产品中广泛利用 AI 和 ML 技术。我们可以从 vSphere 6.7 新版本的功能以及AppDefense和Workspace等产品中看到这一点。这是将有助于实现未来自动驾驶数据中心愿景的一种智能。VMware 已经对其如何通过 NVIDIA GPU 的改进支持帮助客户在 vSphere 上运行自己的 ML 工作负载进行了性能基准测试。

对于 VMware 混合云愿景，ML 非常重要，因为 ML 有能力吸收大量数据，并利用它进行精确学*以及与最终用户一起使用。

基于 ML 的数据分析

机器学*正帮助客户从大量数据集中获取更好的细粒度信息。这将为企业带来巨大的竞争优势，因为客户能够从不同的来源整合他们的数据，这将帮助管理层在竞争对手之前做出重大决策。正如我们得到这个结果及其背后的相关原因，我们可以帮助客户获得准确且高效的数据。人工智能在我们日常生活中的潜力是巨大的。

我们每天都在机器学*方面有新的发展，机器学*将被进一步扩展。所有最大的公共云服务提供商都在他们的日常运营中使用基于机器学*的技巧。苹果、通用电气（GE）和博世（Bosch）也在收集大量数据，并应用机器学*技术来过滤出只有有用的数据。通用电气通过其工业互联网积累数据分析，苹果从其数百万最终用户那里获得了大量的消费者和健康数据，这帮助他们成为人工智能领域的主要参与者。

在现有的云技术中嵌入人工智能，正帮助企业和消费者增长，同时也创造了新的机会，利用所有相关信息来规划未来。我们正朝着智能基础设施迈进，其中人工智能使用机器来采纳人类智慧。人工智能基于基于规则的逻辑、决策树和方法，使其能够像人类一样行为。机器学*分析数据并提高重复性任务的表现。深度学*将帮助机器通过定位和检查各种选项以获得最佳结果或解决方案。

客户已经采用了云计算，现在正在嵌入机器学*技术和其能力，以扩展其动态性并向客户交付价值。客户获得了一个安全且可靠的环境，具有扩展和扩展的能力。作为回报，云服务提供商获得了忠诚的长期客户。每个云服务提供商在特定领域都比其他云服务提供商更好，从商业和人工智能的角度来看。这将为客户提供多样化的产品，为他们的独特需求提供专业化的智能。

虚拟机（VMware）将帮助客户获得智能基础设施，能够在混合云中提供可比较且安全的解决方案，以选择适合其独特业务需求的正确云服务提供商，例如安全、备份、灾难恢复、网络、存储、图形和具有基本计算资源的管理。

智能技术的良好例子是谷歌地图。当我们离开办公室参加会议时，在谷歌地图的指引下，我们能够通过人工智能识别替代路线，节省宝贵的时间。

使用虚拟化 GPU 进行机器学*

机器学*目前在研究和开发中被广泛使用，加速器如 GPU 的计算能力提升使得机器学*应用的快速采用成为可能。

设计师、工程师和建筑师是广泛的最终用户，他们经常使用 3D 图形进行广泛的用例，并期望他们的 IT 团队能够协助他们。他们使用高端图形工作站，实时处理汽车、制造组件和建筑物的 3D 模型。他们是制造、建筑、工程和建设、高等教育、公共部门、石油和天然气等行业的一部分。他们必须实时查看和控制这些丰富的二维和三维数据。像临床医生、工程师和办公室专业人士这样的高级用户群体代表了数百万用户，他们依赖于丰富的二维和三维图形来完成他们的工作。

随着全球工作力的足迹扩大，地理上分散的团队使用带有图形的虚拟桌面，无论何时何地，在任意工作站上都可以使用，组织正在不断发展。随着这些高级用户在野外工作，需要从他们的端点设备（如笔记本电脑、平板电脑和移动设备）的任何地方访问应用程序，他们需要与团队成员实时协作，同时降低数据丢失的风险，并完全符合规定。我们必须用 虚拟桌面基础设施（VDI）解决方案重新定义设计师和工程师的工作流程：

带有 NVIDIA GPU 的 VMware Horizon VDI

VMware VDI 解决方案与所有领先的 3D 应用工作站进行了认证——从端点到数据中心的世界级图形在任何设备上均可访问，同时降低运营成本。VMware Horizon 通过协议 Blast 确保，基于 NVIDIA GRID vGPU 技术提供安全、原生、3D 图形，从云端交付到任何端点设备，并从任何地点提供，同时降低运营成本。使用 NVIDIA GRID vGPU 技术在每台虚拟机上执行的图形命令直接传递到物理 GPU，无需在虚拟机管理程序层产生任何开销。

它有助于应用程序兼容性，因为应用程序可以访问与之前在他们的工作站上相同的显卡。NVIDIA GRID vGPU 使得 GPU 硬件能够进行时间切片，以提供最佳的共享虚拟化图形性能。

VMware、vSphere 和 VMware Horizon 确保高级用户、设计师和工程师能够获得与原生硬件相当且由 NVIDIA 和 VMware 认证的出色图形体验，适用于大多数重要的商业应用。

GPU 使用模式

在 vSphere 上托管的虚拟机中运行的应用程序可以利用 GPU 处理能力以两种方式。

vSphere DirectPath I/O 是 vSphere 的固有功能，它利用配置到主机的 虚拟化技术（VT）启用处理器来提高虚拟机的性能。通用输入输出（GPIO）是英特尔/AMD CPU 的处理器功能，称为 I/O 内存管理单元，它分配直接内存访问传输和设备中断。这样，虚拟机能够绕过 VMkernel 并直接访问底层物理硬件。支持使用 DPIO 启用服务器硬件的 vMotion。

硬件辅助 I/O MMU 虚拟化在英特尔处理器中称为 英特尔定向 I/O 虚拟化技术（VT-d），在 AMD 处理器中称为 AMD I/O 虚拟化（AMD-Vi 或 IOMMU）。这是芯片组的一项功能，它帮助虚拟机直接访问硬件 I/O 设备，如网卡、存储控制器和 GPU。

NVIDIA GRID GPU 支持虚拟化 vGPU，这是在虚拟化环境中多个用户共享单个物理 GPU 的能力。对于 Horizon View 虚拟桌面，有三种基于硬件的图形加速配置可能。vGPU 提供最佳的性能和兼容性选项。

比较机器学*工作负载和 GPU 配置

我们可以通过使用三个不同的 GPU 配置来测试相同的机器学*工作负载；这些配置如下：

• 在 vSphere 上使用 DirectPath I/O 的 GPU

• vSphere 上的 GRID vGPU

• 纯金属主机上的原生 GPU

我们已经测试并发现，虚拟化层（DirectPath I/O 和 GRID vGPU）为测试的机器学*应用引入了仅 4% 的开销。学*时间可以通过使用不同配置的两个虚拟机与特定模型进行比较。

带有和没有 GPU 的两个虚拟机的 VM 资源以及操作系统：

• NVIDIA GRID 配置：1 个 vGPU，12 个 vCPUs，60 GB 内存，96 GB SSD 存储，CentOS 7.2

• 无 GPU 配置：无 GPU，12 个 vCPUs，60 GB 内存，96 GB SSD 存储，CentOS 7.2

让我们看一下以下表格：

MNIST 工作负载	1 vGPU（秒）	无 GPU（秒）
标准化学*时间	1.1	10.01
CPU 利用率	9%	45%

如前表所示，vGPU 将训练时间缩短了 10 倍，CPU 利用率也下降了 5 倍。机器学*可以参考以下两个组件：

• 从 TensorFlow 库派生出的卷积神经网络模型。

• 加拿大高级研究学院（CIFAR）-10 数据集定义了图像数据集，我们利用这些数据集在机器学*和 IT 视觉算法中。

DirectPath I/O

首先，我们关注从单个 GPU 到四个 GPU 的扩展过程中的 DirectPath I/O（DPIO）透传模式：

CIFAR-10	1 GPU	2 GPUs	4 GPUs
相对于 1 GPU 的每秒标准化图像数（千）	1.1	2.01	3.77
CPU 利用率	23%	41%	73%

每秒处理的图像数随着服务器上 GPU 数量的增加而提高。一个 GPU 几乎用于将数据归一化到每秒 1,000 张图像，并且随着 GPU 数量的增加而进一步增长。通过在两种模式下配置一个 vGPU/VM，可以比较 DPIO 和 GRID vGPU 模式的性能：

MNIST 工作负载****（数值越低越好）	DPIO	GRID vGPU
每秒归一化训练时间	1.1	1.03
CIFAR-10 工作负载****（数值越高越好）	DPIO	GRID vGPU
每秒归一化图像数	1.1	0.83

DPIO 和 GRID 模式 vGPU 的性能与一个 vGPU/VM 大致相同。我们可以在 DPIO 中配置具有主机上所有可用 GPU 的虚拟机，但在 GRID vGPU 模式下，虚拟机最多只能配置一个 GPU。我们可以区分运行相同作业的四个虚拟机和在 DPIO 模式下使用四个 GPU/主机的一个虚拟机：

CIFAR-10 工作负载	DPIO	DPiO (四个虚拟机)	GRID vGPU (四个虚拟机)
每秒归一化图像数（数值越高越好）	1.1	0.96	0.94
CPU 利用率	73%	69%	67%

我们应该在多 GPU DPIO 模式下配置具有低延迟或需要更短训练时间的虚拟机。由于它们专门用于特定的虚拟机，在此期间其他虚拟机将无法访问主机上的 GPU。我们可以通过在 GRID vGPU 模式下配置 1-GPU 来利用具有较长延迟或学*时间的虚拟机，并享受虚拟化优势。

虚拟环境中 GPU 的可伸缩性

Horizon 和 vSphere 支持 vGPU，vGPU 带来了广泛的 API 支持和原生 NVIDIA 驱动程序的极致可伸缩性。NVIDIA GRID GPU 基于 NVIDIA Kepler GPU 架构。NVIDIA GRID GPU 支持在虚拟化环境中为多个用户共享单个物理 GPU 的 vGPU 功能。Horizon 将自动在具有所需 GPU 的计算和存储资源池之间负载均衡启用 vGPU 的虚拟桌面，即使不同的池使用不同的用户配置文件也是如此。如果我们创建两个链接克隆池，一个具有 K120Q 配置文件，另一个具有 K220Q，Horizon 将将第一个配置文件放在具有 K1 卡的主机上，而将后者放在 K2 上，无需任何努力。vGPU 配置文件赋予专用图形内存。GPU 管理器分配内存大小以满足每个用户的特定需求。

ESXi 主机可以高达最多 16 个基于物理 GPU 的图形，供不同的虚拟机/用户共享。

Horizon 提供三种类型的图形加速：

• 虚拟共享图形

• 虚拟共享透传图形

• 虚拟专用图形

• 总内存（包括易失性和非易失性内存）不能超过每个虚拟机的最大内存限制（6,128 GB）

在虚拟机内部容器化 ML 应用程序

vSphere 集成容器架构提供了两种容器部署模型：

1. 虚拟容器主机：vSphere 集成容器利用 vSphere 的原生结构来提供容器。它扩展了 vSphere 的可用性和性能能力（DRS、HA、vMotion），以支持容器化工作负载。容器镜像可以用作虚拟机，开发者也可以将其作为 Docker API 消费。

2. Docker 容器主机：开发者可以按需自行配置 Docker 容器主机，并将它们用作开发沙盒来重新打包应用程序。这种架构补充了敏捷开发实践和 DevOps 方法，如持续集成（CI）和持续部署（CD）。

重新架构与数据和其他应用程序组件/逻辑紧密耦合的内部应用程序将非常昂贵且耗时，因此在不改变应用程序设计的情况下重新打包应用程序可以节省成本。重新打包应用程序的学*曲线很小。

vSphere 集成容器提供了一个选项，可以通过使用 Docker 命令行界面来实例化 Docker 镜像，然后将容器镜像作为虚拟机部署，而不是在 Docker 主机上作为容器部署，这样我们就可以在不重新架构应用程序的情况下获得打包应用程序作为容器的优势。这种方式，我们保持了虚拟机的隔离性。vSphere 集成容器是无需任何新基础设施/专用硬件或无需实施新工具的理想解决方案，用于应用程序重新打包。

重新打包的容器化应用程序可以与其他运行传统或容器化应用程序的虚拟机一起运行。vSphere 集成容器在基础设施级别具有高可用性，无需开发者干预即可支持重新打包的容器。我们还可以利用核心 vSphere 功能，如vSphere 高可用性和vSphere vMotion。

vGPU 调度和 vGPU 配置文件选择

GPU 默认支持等量共享，并且必须根据客户需求配置固定份额。

我们可以使用以下两种选项来配置 GPU：

• 等量共享调度器：物理 GPU 在同一主机上运行的虚拟桌面之间共享。随着虚拟 GPU 被添加或从 GPU 中移除，处理周期的份额会发生变化，而虚拟 GPU 的性能取决于其他虚拟 GPU 是否正在运行或停止。

• 固定份额调度器：无论虚拟 GPU 是否被添加到或从 GPU 中移除，每个 vGPU 都会分配物理 GPU 处理周期的固定份额。即使其他虚拟 GPU 正在运行或停止，这将是恒定的。

在 vSphere 上配置 NVIDIA GRID vGPU 可以使用各种选项来配置 vGPU 配置文件，该配置文件定义了每个虚拟机可以使用的 GPU 内存以及可以共享单个 GPU 的最大虚拟机数量。

vGPU 配置文件提供了一系列具有不同缓冲内存帧大小和头数虚拟 GPU。用户数量将由特定配置文件中附加到每个配置文件的 GPU 的帧缓冲区划分来定义，而头数表示支持的显示器数量，而所有配置文件的最大分辨率将保持一致。以 Q 结尾的 vGPU 配置文件必须遵循与 NVIDIA Quadro 卡相同的认证流程，用于专业图形应用程序。我们可以与这些应用程序获得 100%的兼容性和性能。您可以参考此链接以获取认证应用程序列表：www.nvidia.com/en-us/design-visualization/solutions/virtualization/。

高级用户和设计师配置文件

我们可以使用NVIDIA Grid和Horizon将最苛刻的终端用户迁移到数据中心。我们可以通过移动性、易于管理、集中式数据和安全、灾难恢复保护以及其他虚拟化优势来帮助这些用户。我们可以通过将它们依次连接到桌面来将这些用户与其工作站绑定。尽管虚拟专用图形加速（vDGA）透传允许以 1:1 的比例远程访问工作站，但成本较高且没有进行任何资源优化，现在，我们可以混合工作站用户和任务/知识用户以实现更好的资源优化。我们在设计具有所需兼容性和性能的解决方案时有很多选择。通过利用 NVIDIA 平台，我们可以通过认证的软件和硬件获得高质量的设计应用程序体验。配置文件的选择取决于主要应用程序的要求，基于这些要求，我们可以选择合适的 Quadro 认证 vGPU 配置文件以满足最终用户的需求。

知识和任务用户配置文件

任务工作者大多需要软 3D，这是一个适用于图形密集度较低的应用程序的基于软件的 3D 渲染器。他们不需要，或从基于硬件的 3D 加速中获得明显的优势。软 3D 是 Horizon 的标准组件。

办公人员和高管属于此配置文件，主要使用 Microsoft Office、Adobe Photoshop 和其他非专业终端用户应用程序。虚拟共享图形加速（vSGA）解决方案可以通过为跨 GPU 的用户提供高水平的整合来优化此用例的性能。vSGA 不提供广泛的图形 API 支持，因为对于知识工作者来说，始终考虑基于 vGPU 的解决方案会更好。

使用 vGPU Manager 向集群添加 vGPU 主机

我们必须安装 NVIDIA GPU 管理器vSphere 安装包（VIB），因为 NVIDIA VIB 包含主机识别 GPU 所必需的驱动程序。这将为您提供vGPU 管理器。在安装受支持的 vCenter 和 ESXi 版本之前，ESXi 主机的 BIOS 电源和性能设置应设置为高性能策略。ESXi 主机通过 vCenter 进行管理，并配置 NTP 和 DNS。

vGPU 管理器 VIB 在虚拟机管理程序中加载的方式与驱动程序相同。vGPU 管理器可以为每个物理 GPU 分配多达八个用户。M60 可以设置为每张卡 32 个用户。此集群必须具有具有 NVIDIA Tesla M60 vGPU 的主机。这是为了优化 GPU 资源的分配。

使用 NVIDIA GPU 的机器学*

机器学*帮助计算机以一种用户友好的方式在没有明确编程的情况下工作，因此任何人都可以在日常生活中学*并利用它，例如在健康、研究、科学、金融和智能系统中：

在 NVIDIA GRID vGPU 中分配 GPU

Horizon 中的池和农场设置

我们必须像在 Horizon 中配置普通农场一样配置一个 3D 农场：

1. 以我们以前在 Horizon 中配置池的方式配置此池，直到我们达到桌面池设置部分。

2. 在添加桌面池窗口中滚动到远程显示协议部分。

3. 在 3D 渲染器选项中，我们必须在以下两个选项中选择两个：

   1. 对于 vSGA 选择硬件或自动。

   2. 对于 vDGA 或 MxGPU 选择硬件。

4. 在桌面池设置中将默认显示协议设置为 PCoIP，并允许用户在 3D 渲染器下拉菜单中选择“否”以选择 NVIDIA GRID VGPU。

5. 要启用 NVIDIA vGPU，请为虚拟机启用 vGPU 支持：

1. 关闭虚拟机。

2. 在导航器窗口中单击 VM。选择“管理”选项卡和“设置”。单击编辑按钮：

1. 单击“新 PCI 设备”栏，选择“共享 PCI 设备”，然后添加以继续：

1. 现在显示 NVIDIA GRID vGPU 设备已添加。

2. 使用 GPU 配置选择栏配置 GPU，然后单击“确定”完成配置。

配置硬件加速图形

我们可以通过三种方式使用 VMware Horizon 配置加速：

• 虚拟共享图形

• 虚拟专用图形

• 虚拟共享直通图形

虚拟共享图形加速

vSGA 是支持 DirectX 和 OpenGL 的驱动程序。vDGA 配置确实使用了原生显卡驱动程序。SVGA 或 VMware SVGA 3D 是包含在 Windows 虚拟桌面 VMware Tools 中的符合 VMware Windows Display Driver Model 的驱动程序。此 3D 图形驱动程序可以安装在 Windows 上用于 2D/3D，也可以用于 3D 和 vSGA 软件。

VMware SVGA 3D 可以配置为 2D/3D 软件和 vSGA 部署，并且可以通过软件或硬件加速快速在虚拟桌面之间切换，而无需更改现有配置。vSGA 支持具有硬件加速图形配置的 vMotion。通用驱动程序无需进一步配置即可跨平台工作：

服务器的物理 GPU 被虚拟化，并通过 vSGA 技术与其他位于同一主机服务器上的虚拟机共享。我们必须在虚拟机管理程序中集成特定的驱动程序，所有虚拟机都将利用 VMware vSGA 3D 驱动程序。vSGA 在少数没有所需 API 支持的应用程序中具有性能限制，并且对 OpenGL 和 DirectX 的支持有限。

在虚拟机中配置 vSGA 设置

在 vSphere 和 View Pool 设置中存在三个现有的 3D 设置。我们可以通过 vSphere 启用或禁用 3D，将 3D 设置设置为自动。如果我们更改 3D 配置，则视频内存将恢复到默认值 96 MB，因此在更改视频内存之前请务必确认。这些配置具有以下选项：自动（默认），软件，和硬件：

1. 启用 3D 支持。

2. 将 3D 渲染器设置为自动或硬件。

3. 决定 3D 视频内存。默认情况下为 96 MB，但最小可以是 64 MB，最大可以是 512 MB：

vGPU 的虚拟机设置

现在我们将设置 vGPU 的虚拟机设置，以下截图将展示：

前面的图像将根据应用需求提供多种配置选项，并包含所有安全措施。

1. 选择要配置的虚拟机并点击“编辑设置”。首先，添加一个共享 PCI 设备，然后选择 NVIDIA GRID vGPU 以在虚拟机上启用 GPU 直通：

1. 从 GPU 配置文件下拉菜单中选择所需的配置文件：

GPU 配置文件字符串 4q 通知帧缓冲区（VRAM）的大小（以 GB 为单位）和所需的 GRID 许可证。

VRAM 0,1 分别通知 512 MB，1,024 MB，依此类推。GRID 许可证类型如下：

• GRID 虚拟 PC vGPU 用于商业桌面计算通知使用b：

• GRID 虚拟应用 vGPU 用于远程桌面会话主机通知使用a：

• Quadro 虚拟数据中心工作站（vDWS）针对工作站特定的图形特性和加速功能，例如最多支持四个 4K 显示器和针对专业应用的认证驱动程序，通过q通知：

在创建虚拟机时点击“保留所有内存”。我们可以管理端到端 NVIDIA 虚拟 GPU 解决方案，如 Quadro vDWS 和NVIDIA GRID 虚拟 PC（vPC），在主机、客户机或应用层对其整个基础设施实现完整的 vGPU 可见性。这有助于我们更加灵活和快速响应，从而为终端用户带来更好的 VDI 体验。

我们可以从高端虚拟工作站到企业虚拟工作空间提供更好的用户体验，这些工作空间购买成本低、部署简单、运行高效。

使用基于 Pascal 架构的 GPU 以及 Quadro vDWS 软件的工程师、设计师、内容创作者和建筑师能够体验到在任意虚拟工作站或笔记本电脑上运行加速图形和计算（CUDA 和 OpenCL）工作负载的最佳效果。

知识工作者使用 Windows 10、Office 365 和 YouTube 等程序，这些程序需要图形加速，以便通过搭载 NVIDIA Pascal™架构 GPU 的 NVIDIA GRID™虚拟 PC 获得更好的虚拟桌面用户体验。NVIDIA NVENC 通过将 H.264 视频编码从 CPU 卸载到 Linux 虚拟工作站用户，从而提供更好的性能和用户密度，这是一个繁重的计算任务。Horizon 为用户提供了一个单一的平台，可以发布所有类型的桌面（Windows 和 Linux）和应用程序，根据用户的图形需求。

GRID vPC 和 GRID vApps 功能

NVIDIA GRID 提供了基于特定用例的软件版本：

• NVIDIA GRID 虚拟应用程序（vApp）：我们可以用它进行应用程序虚拟化或基于 RDSH 的应用程序发布。

• vPC：它非常适合提供标准桌面应用程序、浏览器和多媒体的虚拟桌面。

• NVIDIA GRID 虚拟工作站（vWS）：这对于使用 CATIA、S、3DExcite、Schlumberger Petrel 或 Autodesk Maya 等强大 3D 内容创建应用程序的科学家和设计师来说将非常有价值。vWS 仅支持这一 NVIDIA Quadro 驱动程序。

NVIDIA GRID 软件版本可以以年度订阅、永久许可或与支持相结合的方式购买。高可用性许可服务器确保用户即使在主许可服务器离线的情况下也能不间断地工作；然后，辅助许可服务器将为客户端提供许可服务。

在基于 Pascal 架构的这次发布中，NVIDIA 虚拟 GPU 解决方案和搭载 Maxwell 架构的 GPU（NVIDIA® Tesla® M60、M6 和 M10）得到支持。NVIDIA 虚拟 GPU 解决方案将在所有搭载 Tesla P40 以及始终推荐的 P6（刀片）GPU 上得到支持，前提是拥有适当的软件许可。

即使您拥有搭载 Maxwell 架构的 GPU 并使用 NVIDIA GRID 解决方案，我们也需要 Pascal 架构的 GPU 才能从性能提升、增加的帧缓冲区、更大和更细粒度的配置文件大小、更大的系统内存、在同一个 GPU 上运行虚拟化图形和计算工作负载的能力以及利用新的任务调度器中受益。

特性如简化管理和监控，有助于在应用层监控和集成方面在 NVIDIA GRID 软件发布和 GRID Management SDK 2.0 上同时工作在 Maxwell 和 Pascal 卡上。我们必须为特定的工作负载选择推荐的 Pascal/Maxwell 板。

我们可以为商业客户推荐 P40 或 M60。P40 提供最高性能、更大的内存和更易于管理，并支持图形和计算（CUDA 和 OpenCL）的虚拟化。当从 M60 或 K2 或基于 Skylake 的服务器升级时，建议使用 P40。M60 将继续提供，并提供异构配置文件和更大的 OEM 服务器支持。

对于密度驱动的部署的客户，建议使用M10，而对于运行日常图形加速应用的知識工作者，建议使用 M10。对于高密度刀片服务器部署，建议在 M6 之后使用 P6。

GRID vWS 到 Quadro vDWS

我们可以利用 Quadro/GRID 功能，并将其与 VMware 虚拟工作站/PC/虚拟应用解决方案进行比较。NVIDIA GRID vWS 现在是NVIDIA Quadro 虚拟数据中心工作站或Quadro vDWS。GRID 品牌将用于描述 PC 体验，并将有两个版本：NVIDIA GRID vPC 和 NVIDIA GRID vApps。虽然这两个软件版本曾经被称为 NVIDIA GRID 软件平台，但它们现在将被称为NVIDIA 虚拟 GPU 解决方案。

MxGPU 是一种 GPU 虚拟化技术，内置硬件引擎负责虚拟机调度和管理。它根据应用程序的要求利用底层 SR-IOV 协议。处于直通模式的 GPU 不能虚拟化，因此首先运行脚本以禁用直通模式。如果 MxGPU 已启用且 vCenter 可访问，则使用插件进行配置而不是脚本。vDGA 可以通过提供对物理 GPU 的直接直通，帮助用户获得不受限制和专用的单 vGPU 访问。使用 MxGPU 设备在虚拟机上安装驱动程序的步骤与 vDGA 下的常规直通设备相同。

在使用 MxGPU 和 vDGA 时配置虚拟机：

1. 对于具有大 BAR 大小的设备，例如 Tesla P40，我们必须在虚拟机上设置配置参数：

   • firmware="efi"

   • pciPassthru.use64bitMMIO="TRUE"

   • pciPassthru.64bitMMIOSizeGB="64"

2. 向特定虚拟机添加 PCI 设备，并选择所需的 PCI 设备以启用 GPU 直通：

1. 通过主页上的管理员账户登录 vSphere Web Client，点击 Radeon Pro 设置。转到数据中心，并管理特定数据中心中的所有 MxGPU 主机。

2. 我们可以在 vSphere Client 插件上安装 Radeon Pro Settings，使用 MxGPU：

VMware 支持 AMD 和 NVIDIA 图形卡。我们可以从供应商网站下载适当的 VMware 图形驱动程序来使用图形卡或 GPU 硬件。我们还可以将 PCI 设备添加到单个虚拟机以及多个虚拟机中。

1. 要使用命令一次性为多个虚拟机添加 PCI 设备，请执行以下操作：

   1. 浏览到 AMD FirePro VIB 驱动程序并安装 AMD VIB 实用程序：cd /<path_to_vib from ssh>。

   2. 编辑vms.cfg：vi vms.cfg。

2. 按I键，并将.*实例更改为与需要 GPU 的 VM 名称匹配，例如将*MxGPU*更改为包含 MxGPU 的 VM 名称：.MxGPU。

3. 通过按Esc键保存并退出，输入:wq并按Enter键。

4. 将虚拟功能分配给 VM：

sh mxgpu-install.sh –a assign 
Eligible VMs:
WIN10-MxGPU-001
WIN10-MxGPU-002
WIN8.1-MxGPU-001
WIN8.1-MxGPU-002
These VMs will be assigned a VF, is it OK?[Y/N]y

1. 按Enter键并选择保留所有客户内存（全部锁定）。

2. 使用 MxGPU 脚本重新启动系统以自动分配虚拟功能（VF）。

我们应该验证所有 VF 是否已填充在设备列表中。这样，我们可以通过使用脚本自动分配 VF。

摘要

对于像 CAD/CAM、诊断成像、分子设计和太空探索等应用程序的远程计算解决方案，证明是难以实现的。NVIDIA GRID vGPU 技术和 VMware、vSphere 和 Horizon 虚拟化软件为设计工程师、科学调查人员和数据探索者提供了成本效益的解决方案。

Horizon 提供基于软件的图形加速，这对于基本使用是足够的，但基于硬件的图形加速有不同组合的 GRID 图形卡与服务器配置，可以用来满足广泛的先进用户需求并在预算内完成。我们可以将 GPU 配置为两种模式：

• DirectPath I/O 透传模式

• GRID vGPU 模式

虚拟化 GPU 的共享访问使沉浸式 3D 图形应用程序可以从远程设备访问。这种解决方案消除了对专用图形工作站的需求，提高了安全性，并使用户摆脱了办公室的束缚。

下一章将介绍以提供最终用户自由和基于基于 ML 算法的策略操作的全控制权给管理员/服务提供商的托管应用程序的策略，这将也有助于提高最终用户体验。

进一步阅读

• VMware 文档

• VMware 兼容性指南

• vSphere 6.0 配置最大值指南

• VMware vCenter Server 数据表

• VMware vSphere 数据表，请参阅 www.vmware.com/files/pdf/vsphere/VMW-vSPHR-Datasheet-6-0.pdf

• VMware Horizon 7 数据表，请参阅 www.vmware.com/files/pdf/products/horizon/vmware-horizon-7-datasheet.pdf

• 每个解决方案组件的多站点部署最佳实践，请参阅 www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vmware-horizon-7-enterprise-edition-reference-architecture-multi-site.pdf

• NVIDIA vGPU 部署指南针对 VMware Horizon 7.x，请参阅 images.nvidia.com/content/pdf/vgpu/guides/vmware-horizon-vsphere-deployment_guide.pdf

• 准备 NVIDIA GRID vGPU 功能——VMware 文档，请参阅 docs.vmware.com/en/VMware-Horizon-7/7.6/horizon-virtual-desktops/GUID-AB1B6311-DB31-4982-ACDF-0E1A5ED3B17D.html

• 在 Horizon Administrator 中配置桌面池，以及完整信息和详细步骤，请参阅 www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/horizon/grid-vgpu-deployment-guide.pdf

第二章：使用 vSAN 高级分析进行主动措施

本章将简要介绍虚拟存储区域网络（vSAN）设计建议，以及所有监控选项，通过这些选项您的客户可以评估、推荐和设计他们的环境。这将帮助他们通过智能策略自动化操作来实现不同的业务目标。

我们将学*如何根据机器学*算法配置策略操作，并了解通过主动解决客户问题如何提升最终用户体验。我们还将学*如何优化超融合基础设施（HCI）以实现客户业务目标。

本章将涵盖以下主题：

• vSAN 上的应用可伸缩性

• 智能监控

• 弹性集群中的高可用性（HA）配置

• 基于存储策略管理（SPBM）的 vSAN 策略设计

技术要求

您可以从my.vmware.com/web/vmware/details?downloadGroup=VC65U1&productId=676&rPId=28154网站下载 VMware vCenter Server 6.5 U1。.

vSAN 上的应用可伸缩性

VMware vSAN 可以支持容器和基于更新后的 vSphere Docker 卷驱动程序的下一代应用，该驱动程序通过 Docker API 提供原生支持。这使得 Docker 可以在 vSAN 之上构建，并利用 vSAN 经过验证的持久化存储功能。此驱动程序更新具有新功能，包括对多租户、SPBM、克隆和快照的支持。VMware 有一个“API 优先”的原则，所有管理功能都可通过 API 访问，这些 API 是成千上万的企业客户使用的 vSphere API 的扩展，他们使用这些 API 来自动化他们的操作。

应考虑以下参数以确定应用数据应存储的存储层：

• 每秒 I/O 操作数（IOPS）要求

• MBps 要求

• 容量要求

• 可用性要求

• 延迟要求

• 考虑任何现有的服务级别协议（SLA）

• 考虑数据在信息生命周期中是否可能在存储层之间移动

这些详细信息可用于将应用程序和服务移动到具有匹配特性的设计存储层。

存储和网络评估

对 vSAN 管理的整体方法可以对基础设施产生显著积极影响。它与 vRealize Operation 集成，并通过提供更多关于资源的深入信息来补充它。以下 VMware 推荐从三个不同的角度看待业务挑战：

• 组织建议：采用以服务为中心的方法，如提供一系列服务和级别，来制定虚拟化策略。

• 操作建议：重点关注流程定义和改进，特别是在资源分配、系统监控和问题管理领域。研究和评估虚拟基础设施监控工具。

• 技术建议：在类似系统中实施一致的配置，进行微小的网络调整，以在竞争和备份窗口期间显著提高网络性能，并配置虚拟机以利用虚拟化的好处。

存储设计策略

评估摘要基于VMware 健康分析器（vHA）检查点和记录的 vSAN 最佳实践。我们将在下一节中查看一些建议。

VMware 最佳实践建议

以下是一些 VMware 的最佳实践，以及存储设计策略的建议：

• 在 vCenter 控制台中验证我们是否已正确设置了存储策略：

  • 默认规则设置应默认修改。应根据您的需求应用策略。

  • 策略设置：在配置期间，强制预配应设置为 true。

  • 对象空间预留（%）应设置为 100%。

理由：vSAN 中的虚拟机存储策略可能会影响在 vSAN 数据存储上运行的虚拟机的性能。这包括每个对象的磁盘条带数、闪存读取缓存预留（%）、容忍故障数和对象空间预留（%）参数。

VMware 建议您采用默认策略，即容忍一次故障和一条磁盘条带。我们可以根据客户需求更改策略，也可以更改配置。我们必须为每个额外的容忍故障更新策略。需要2n+1个主机来满足策略，其中n是容忍故障的数量。

• 验证虚拟机是否均匀分布在 vSAN 节点上。正如磁盘资源应通常均匀分布在 vSAN 主机上一样，为了获得最佳性能，虚拟机也应相对均匀地分布在那些主机上。

理由：这减少了由于单个主机上虚拟机不平衡而影响性能的可能性，这可能导致 vSAN 网络饱和。vSphere 的分布式资源调度器（DRS）可以通过监控和根据需要平衡虚拟机来帮助磁盘资源分配。

• 存储控制器的设置应配置正确以获得最佳性能。

理由：vSAN 中的虚拟机存储策略可能会影响在 vSAN 数据存储上运行的虚拟机的性能。控制器队列深度低可能会在重建/同步期间影响生产虚拟机的可用性，因此 vSAN 需要至少 256 的最小队列深度。vSAN 的 VMware 兼容性指南已更新，仅包括满足此要求的适配器。然而，某些具有较旧固件的适配器可能仍然人为地限制了队列深度。控制器应禁用缓存。如果不可能这样做，则将读取缓存设置为 100%。如果控制器未设置为直通模式，则将每个磁盘作为其自身的设备呈现。不要将驱动器配置为一个大型 RAID 卷。

• 除非绝对必要，否则请避免使用闪存读取缓存策略预留。

理由：vSAN 允许为虚拟机使用自定义策略。策略选项之一，闪存读取缓存预留（%），允许预留读取缓存。除非绝对必要，否则不要设置此策略选项。这些预留将读取缓存的一部分分配给基于容量磁盘大小的对象（250 GB 磁盘的 10%为 25 GB）。如果不节约使用，缓存预留会迅速减少可用的缓存和 vSAN 的有效性。

• 我们应将磁盘上的文件格式升级到 3.0。

理由：为了在 vSphere 中使用 vSAN 的全部功能，请确保升级磁盘上的文件格式。在从版本 5.5 升级到版本 6.7 的 vSAN 升级过程中，可以保持磁盘上的格式版本，即 1.0，但无法使用许多新功能。vSAN 支持两种磁盘格式。

• vSAN 应使用最优的 非易失性内存表达（NVMe）E 类磁盘。请确认您正在使用受支持和高性能的 固态硬盘（SSD）以获得最佳性能。

理由：所有写入首先命中 vSAN 中的 SSD。vSAN 读取缓存命中来自 SSD，因此 SSD 的性能是 vSAN 总体性能的关键因素。

我们还可以使用 SSD 代替磁碟作为容量层。VMware 兼容性指南通过根据性能将它们分成不同的组来帮助客户选择正确的 SSD，如下所示：

• A 类：每秒 2,500–5,000 写入

• B 类：每秒 5,000–10,000 写入

• C 类：每秒 10,000–20,000 写入

• D 类：每秒 20,000–30,000 写入

• E 类：每秒 30,000+ 写入

VMware 始终建议使用满足应用程序性能需求的闪存驱动器以获得最佳性能。根据最佳实践，在应用容错策略之前，我们必须考虑预计使用的 10% 的 硬盘驱动器（HDD）容量。

网络设计策略

vSAN 需要一个 VMkernel 网络配置来同步和复制活动。这个端口组通常应该是专用和隔离的，用于 vSAN 流量。然而，如果使用 10 千兆网络接口，它可以共享。1 千兆网络需要为端口组分配一个专用的网络接口卡（NIC）。

以下是与 vSAN 网络配置相关的重大决策点：

• 网络速度要求：所有闪存 vSAN 配置（包括高级和企业版）仅适用于 10 千兆以太网网络上行链路。要实现最高性能（IOPS），需要 10 千兆网络。VMware 建议使用 10 千兆以太网连接（MTU 9000）用于所有配置的 vSAN。

• 要使用的虚拟交换机类型：vSAN 支持 vSphere 标准虚拟交换机配置和分布式交换机配置。分布式交换机允许使用网络 I/O 控制来优先处理带宽。它允许接口共享，并在争用场景中优先级处理性能水平。VMware 建议为 vSAN 端口组使用vSphere 分布式交换机（VDS）。

• 巨帧：vSAN 支持在 vSAN 网络传输中使用巨帧。VMware 建议为 vSAN 使用巨帧，但前提是底层物理环境已经配置为支持它们。

• 业务连续性和灾难恢复（BC/DR）和团队考虑因素：在任何环境中，网络故障发生时，BC/DR 都是至关重要的。vSAN 支持网络卡的团队配置，以增强网络的可用性和冗余。VMware 建议在环境中使用基于物理适配器负载的路由的主动/主动冗余配置进行团队配置。空闲的网络卡不会等待故障发生，并在这种配置中聚合带宽。

VMware 最佳实践建议

以下是与网络设计策略相关的 VMware 最佳实践和建议：

• 我们应该在各种外围组件互连（PCI）总线上分配端口组的 VMNIC，以增强可用性

理由：在 PCI 总线上分配端口组的 VMNIC 可以防止与特定 PCI 总线相关的故障。您需要将来自不同 PCI 总线的 VMNIC 进行团队配置，以提高从组件故障中恢复的容错能力。

• 一致地配置网络接口卡（NIC）、物理交换机速度和双工设置

理由：错误的网络速度和双工设置可能会影响性能。必须检查网络适配器（VMNIC）和物理交换机的设置，并正确设置。如果您的物理交换机已配置为特定的速度和双工设置，我们必须强制网络驱动程序使用相同的速度和双工设置。网络设置应设置为自动协商，而不是强制设置为千兆链路。我们可以从 vSphere 客户端设置网络适配器的速度和双工设置，但需要重启才能使更改生效。

• 始终建议使用 10 千兆或更快的网络与 vSAN 一起使用

理由：小型 vSAN 部署可以在 vSAN 集群中的 ESXi 主机之间使用 1 千兆以太网链路时表现良好，但大多数部署将需要 10 千兆或更快的链路。VMware 建议使用至少 10 千兆的链路以获得最佳数据存储性能。

• 网络 I/O 控制（NIOC）的份额配置确保至少有 8 千兆比特的带宽可供 vSAN 流量使用，以避免争用。在使用 NIOC 的同时，我们将使用 vSAN 预留。

理由：VMware 建议为特定的用例预留 vSAN 资源，但主要是为了物理网络的环保条件，从而减少实际带宽。这可以在物理 NIC 和物理网络之间进行调度。预留确保 vSAN 网络流量不会被其他流量类型消耗。NIOC 可以将预留的带宽重新分配给其他系统流量类型（管理、互联网小型计算机系统接口（iSCSI）、容错（FT）、vMotion 等），但不能分配给 VM 流量。即使有最小量的管理流量，VM 流量也不会出现任何拥塞。

• 多播网络已启用，以实现高效操作，因为一个多播组不包含任何网络分区

理由：vSAN 需要使用互联网组管理协议（IGMP）嗅探的多播网络。我们应该通过运行网络发现命令来验证网络基础设施是否支持这一要求。基础设施将需要为 vSAN 网络配置嗅探器载体，或者在某些环境中默认使用的 VLAN 或端口上显式禁用 IGMP 嗅探。处理 vSAN 流量的所有物理交换机和路由器，以及第二层路径和第三层（可选）路径，都应该启用多播。VMware 建议使用第二层多播，因为它配置和操作简单。

VMware 的客户体验改进计划/vSAN ReadyCare

我们已经添加并开发了一些增强功能，这些功能是基于过去 6-12 个月内客户反馈的。VMware 检索有关客户环境中部署的 VMware 解决方案的技术数据，以及其他与客户 VMware 许可证密钥集成的服务。

根据 VMware 产品或服务的性质和客户选择的参与程度，积累的技术数据包括以下所有或部分数据：

• 配置数据提供有关 VMware 解决方案配置的信息，以及部署在客户环境中的相关产品，如 VMware 产品的版本、配置细节以及与 VMware 产品/服务相关的应用程序/硬件配置

• 产品特性特定数据，提供有关 VMware 工具在客户数据中心中如何使用的信息，包括用户界面活动和与第三方工具的集成

• 性能数据有助于测量各种 VMware 产品特性的性能，如可用性/可伸缩性/安全性，以及用户界面和 API 集成的响应时间

• 从初始部署到生产阶段由 VMware 产品产生的产品日志数据，例如过去系统事件的日志和特定时间段内不同的系统状态，不包含客户的应用数据/内容

VMware 定期更新所有这些信息，通过客户体验改进计划（CEIP）反映其产品/服务的变更，我们始终建议我们的客户定期浏览此网页（CEIP）以保持最新：www.vmware.com/in/solutions/trustvmware/ceip.html。

我们现在将看到如何使用机器学*技术收集日志和进行监控。

智能监控

vSAN 环境监控对于成功的部署至关重要。我们必须遵循以下监控实践：

• 一般监控实践

• vSAN 健康检查插件

• vSAN 观察者

• VMware vRealize Operations Manager 监控

• 监控设计

一般监控实践

vSAN 支持通过 VMware vSphere Web 客户端、HTML 5 客户端和 vSAN 管理 API 监控数据存储。vSphere Web 客户端监控不同的对象，如集群和数据存储。

没有对基础设施的有效控制，虚拟机或 ESXi 主机蔓延可能会迅速降低虚拟化的投资回报。改进的领域包括评估工作负载以确定性能指标，然后可以使用这些指标创建针对特定虚拟机的 vSAN 策略，以更好地适应工作负载。对于大于缓存磁盘大小的写密集型工作负载，采用两个节点的条带策略可能会提高性能。我们可以最小化由操作团队在出现性能相关问题的虚拟机上花费的故障排除时间。

vSAN 健康检查插件

vSAN 健康检查插件是一种简单的方法来检查 vSAN 集群的健康状况。它默认包含在安装中。健康检查的技术建议如下：

优先级	组件	推荐操作项
P1	vSAN	验证 vSAN 固件和驱动程序版本。
P2	vSAN 网络	将端口组的 VMNIC 分布在不同的 PCI 总线上，以提供更大的冗余。
P3	vSAN 网络	一致地配置网络接口卡（NIC）、物理交换机速度和双工设置。对于 1 千兆位 NIC，设置为自动协商。
P3	vSAN	确认您已正确设置存储策略。
P3	vSAN	确认虚拟机在 vSAN 节点上均匀分布。

VMware 建议使用健康检查插件，以便轻松监控 vSAN 集群。

vSAN Observer

vSAN Observer 对磁盘组进行深入监控，显示组层和磁盘层的汇总视图，并监控 vSAN 物理磁盘层的延迟。它读取缓存命中率、驱逐和性能以及其他参数，如大小、磁盘类型、制造商、型号、本地/非本地等。vSAN Observer 是 Ruby vSphere Console（RVC）的一部分，它支持在 Windows 平台上使用 vCenter Server 证书，并提供网络、基于内容的读取缓存（CRBC）和 vSAN 稀疏统计。以下工具/数据可以帮助您的客户解决与 vSAN 相关的问题：

• vSAN 配置

• vSAN 健康监控

• vSAN 磁盘统计

• vSAN 性能统计

• 观察者

vSAN Observer 建议您部署 vCenter Server 虚拟机并在新部署或远程 vCenter Server 虚拟机上运行观察会话，以增加数据收集时间超过默认值（2 小时）。

vSAN Observer 用户界面显示以下性能细节：

• 物理磁盘层的统计

• 详细的物理磁盘组信息

• CPU 使用率统计

• vSAN 内存池的消耗

• vSAN 集群中物理和内存对象的分布

vRealize Operations Manager 监控

当服务中断持续增加且 IT 团队越来越渴望在短时间内找到中断问题时，业务可能会受到严重影响。日志已成为关键的信息来源，并且需要用于解决 IT 运营问题。然而，由于 IT 环境的日益复杂，日志的数量和大小也在增长。

随着客户对成本越来越敏感，VMware Cloud 服务之一的 Log Intelligence 通过提供公共和私有云基础设施的宝贵见解，帮助客户克服这些挑战。Log Intelligence 提供快速 IT 故障排除，跨多个云的深度操作可见性，包括 VMware Cloud on AWS，以及集中日志管理。VMware 建议使用 vRealize Operations Manager 安装和监控 vSAN，这有助于在环境中全面监控 vSAN。

影响业务成果的挑战

以下是一些影响业务成果的挑战：

• 缺乏可见性：没有通过单一视角实现系统级可见性的 IT 团队，在手动审查日志上花费大量时间，阻止他们花时间在更战略性的任务上。

• 被动故障排除：由于触发警报的孤立指标，IT 团队在识别和解决问题上花费太多时间，增加了时间、成本和停机时间。

商业效益

Log Intelligence 是一项服务，提供快速 IT 故障排除，在公共和私有云环境中实现深度操作可见性，以及集中式日志管理，使 IT 团队能够更有效地解码和解决问题。

以下是一些好处：

• 最小化成本：帮助客户提高性能，创建更快的故障解决方法，从而在公司的收入和支出方面节省资金。

• 预防停机：从被动机制转向发现潜在问题并跟踪日志值超出正常操作的日志值的基础设施，防止未来的停机。

• 节省时间：使用集中式日志管理工具自动收集和组织信息。

技术问题

技术问题，如监控和主动支持以减少解决时间，如下：

• 对 SDDC 环境的洞察不足：IT 管理员通常对其组织的云环境，特别是其应用团队在公共云中部署的工作负载，没有良好的可见性。

• 被动性能故障排除：传统的日志管理工具依赖于原始的性能指标，通常在性能阈值超过时仅向管理员发出警报。此外，它们不提供日志文件中的额外见解用于故障排除和根本原因分析。

技术解决方案

Log Intelligence，一款 SaaS 服务，易于上手和使用。IT 管理员可以使用它来收集和分析各种类型的机器生成日志数据。通过日志分析，Log Intelligence 可以连接到基础设施和应用，实现企业级可见性。

Log Intelligence 提供了一个直观的基于 GUI 的界面，使 IT 管理员能够轻松运行简单的交互式搜索，以及进行深度分析查询，以快速洞察，提供即时价值和改进的 IT 效率。

Log Intelligence 优势

让我们来看看 Log Intelligence 的一些优势：

• 立即产生价值：Log Intelligence 从公共和私有云环境中提供自动数据收集，并通过帮助客户高效地摄取通用日志收集和分析，以及提供直观、有趣的事件，实现立即产生价值。

• 成本节约：它通过快速故障排除中的索引和分组创新方法，帮助客户减少升级支持请求的解决时间，在虚拟和云部署中实现快速故障排除。

• 提高生产力：它有一个包含所有相关信息的单一日志管理控制台，这有助于用户在组织中创新新事物

我们现在将了解在弹性集群部署期间可以使用的不同配置参数。

弹性集群中的 HA 配置

VMware vSAN 有在集群中部署两个 ESXi 主机并带有远程见证设备的选项。我们可以为 vSAN 定义特定的 vSphere HA 行为来验证虚拟机的单个状态。如果虚拟机的组件可以从定义的分区访问，vSphere HA 可以指定特定的虚拟机故障转移操作。

以下为集群设置的截图：

启用 HA 的 vSAN 弹性集群在集群设置中有以下配置：

vSphere HA	配置参数
主机监控	是
主机硬件监控 - 虚拟机组件保护：防止存储连接丢失	否，默认
虚拟机监控	否，默认
入场控制	启用
数据存储心跳	使用定义的列表中的数据存储将禁用数据存储心跳，但不需要从该列表中选择任何数据存储

要配置策略以启用 HA，请按照以下步骤操作：

1. 前往 HA 设置（已启用 HA）并配置主机服务器和见证主机上的静态路由

2. 将见证虚拟机的 vSAN VLAN 添加到数据中心 ESXi 主机的 vSAN 网络中

3. vSAN 的流量已启用对 VMkernel 端口组的流量

4. 通过在集群中所有 ESXi 主机上执行esxcfg-route –a命令来添加静态路由，这些主机跨越数据站点和见证主机

5. 使用esxcli命令添加静态路由，如下所示：

esxcli network ip route ipv4 add –n <remote network> -g <gateway to use>

双节点集群

由于 vSAN 至少需要三个主机来确保所有组件都受到保护，因此无法使用 vSAN 配置双节点集群。

可以通过配置向导配置带有见证的双节点集群。这对于较小的环境来说很好。VMware 为双节点配置引入了见证流量分离（WTS），并也支持弹性集群中的此功能。大多数弹性 vSAN 客户通过通过 CLI（esxcli）配置（见证）来利用此功能。我们只需使用以下命令为见证流量标记VMKernel NIC（vmknic）：

esxcli vsan network ip set -i vmk<X> -T=witness

vSAN 集群的见证设备

VMware 有一个 vSAN 见证设备，它基本上是一个运行在虚拟机中的 ESXi 实例，充当见证。与正常 vSAN 集群中的主机或 vSAN 弹性集群数据中心部分的主机相比，见证主机需要的容量、带宽和性能更低。见证设备存储虚拟机的见证组件，并在发生故障或脑裂情况时负责对象法定人数，以确保所需的虚拟机可用。

小型环境中的见证设备配置如下：

• 小型（10 个虚拟机或更少：应用程序/域控制器/文件和打印服务器）

• 两个 vCPU，8 GB vRAM

• 8 GB ESXi 启动磁盘，一个 10 GB SSD，一个 15 GB HDD

• 支持最多 750 个见证组件

配置 vSAN 集群

所有在 VMware HCL 中提到的 VMware vSAN 认证服务器都可以被认为是 vSAN 集群的一部分，该集群利用磁盘和闪存盘作为容量和缓存层。通过减少对较慢磁盘的访问，将 70% 的可用缓存分配用于存储频繁读取的磁盘块，而剩余的 30% 可用缓存分配给写入。应合并多个写入并顺序写入以增强磁盘性能：

1. 选择主机服务器所在的集群。

2. 在右侧点击 配置... 选项来管理所有由 vSAN 驱动的数据存储：

1. 在虚拟存储区域网络（Virtual SAN）下找到配置 vSAN 的选项。

2. 前往配置页面。

3. 然后，转到从数据存储空间声明磁盘，然后选择手动：

1. 故障域 & 扩展集群：配置两个主机 vSAN 集群。

2. 确认 vSAN VMkernel 网络适配器上的网络有效。

3. 验证每个服务器都显示所有磁盘。

4. 将磁盘折叠到它们的逻辑驱动器。然后，将 SSD 设置为缓存层，将 HDD 设置为容量层。

5. 选择故障域和首选故障域以及次要故障域。

6. 点击下一步继续。

7. 选择选择见证虚拟机的选项。

8. 将见证虚拟机主机的容量和缓存层进行映射。然后，部署见证虚拟机以监控 vSAN 集群：

1. 点击完成以完成 vSAN 配置。现在应该可以看到磁盘。

2. 登录到主机服务器并输入以下命令：

localcli vsan cluster get

1. 验证集群显示为健康状态。

2. 在 集群 | 监控 | VSAN 下，运行健康检查以确认配置正确。

我们已经介绍了如何配置 vSAN 集群以及如何执行健康检查监控。现在，我们将了解我们可以通过 SPBM 配置的各种策略。

使用 SPBM 的 vSAN 策略设计

vSphere 中的存储类定义映射到通过 vSAN SPBM 定义的策略，以实现不同级别的服务级别协议（SLAs）和服务质量（QoS），并可以利用这些高级 vSAN 数据服务功能（如去重、压缩和校验和）的优势。如果没有特定的用例，建议使用通用策略。

首先评估以下不同的应用程序需求：

• 每个虚拟磁盘的 I/O 性能和您的工作负载配置文件

• 您工作负载的工作集

• vSphere 的额外缓存热添加功能需要重新填充缓存

• 特定应用程序的最佳实践，例如块大小

基于业务目标定义策略

vSAN 通过使用存储感知的 vSphere API 将存储参数集成到 vCenter 服务器中。SPBM 进一步帮助定义以虚拟机为中心的策略，这些策略基本上是基于可用的存储功能以及各种策略（带有配置参数）存储虚拟机存储预配需求的结构。

这些内容如下：

• 每个对象的磁盘条带数（性能）：默认值 = 01，最大值 = 12

备注：通过定义硬盘的数量，RAID 0 条带配置可以增强虚拟机磁盘的性能。

• 闪存读取缓存预留（%）（性能）：默认 % = 0，最大 % = 100

备注：我们可以专门为虚拟机利用此配置，这些虚拟机必须存在读取 IOPS 问题。这需要解决，但根据 VMware 最佳实践，不应推荐预留。

• 可容忍的故障数，FTT（冗余）：默认值= 01，最大值 = 03

备注：FTT（故障容忍数）决定了存储对象可以容忍的主机、磁盘或网络故障数量。当创建n+1个磁盘副本并且需要2n+1个主机或故障域参与存储镜像时，我们可以容忍n (0, 1, 2, 3)个故障。如果我们有至少四个节点或故障域，并且使用擦除编码，我们可以容忍一个故障；如果至少有六个主机或故障域，我们可以容忍两个故障。如果磁盘大小大于 16 TB，最大值为 1。

这些参数在“配置”界面中进行配置：

• 故障容忍方法（性能/容量）：默认 = RAID 1（镜像）-性能

备注：RAID 1 可以通过使用镜像实现良好的性能来处理故障容忍，而 RAID 5/6 通过使用奇偶校验块以极大的空间效率帮助实现故障容忍。RAID 5/6 仅在所有闪存 vSAN 集群上可用，并且当可容忍的故障数（FTT）设置为1或2时。1 个 FTT 的值表示 RAID 5 配置，2 个 FTT 的值表示 RAID 6 配置。

• 对象的 IOPS 限制（性能）：默认 = 0

备注：磁盘 IOPS 的限制是通过使用定义的大小计算 I/O 的数量。默认情况下，它使用 32 KB 作为基本大小，因此 64 KB 的 I/O 将代表 2 个 I/O。通过将限制设置为0来定义无限制策略。

• 禁用对象校验和（覆盖策略）：默认 = 否

备注：此设置确定是否对写入卷的数据进行校验和计算。校验和计算和错误纠正将在后台执行。

• 强制预配（覆盖策略）：默认 = 否

备注：如果强制预配不会遵守可用资源，则它将覆盖当前策略。

• 对象空间预留（厚预配 %）：默认值 = 0，最大 = 100

备注：它将在 VM 创建时帮助一定比例的厚配置存储对象，而其余的存储对象是薄配置的。当预期的存储量已经用对象填满时，它将有助于减少重复的磁盘增长操作任务。

带 RAID 配置的 FTT 策略

策略是根据应用程序要求配置的，并根据可用的对象应用。以下表格列出了在不同场景中应用的 FTT 策略选项：

RAID-1将在主机服务器上的容错方法中使用。如果我们不使用主机 HBA 模式，那么我们将不得不将单个磁盘作为 RAID 0 进行 RAID。有时，网络上的 RAID 5 和 RAID 6 也被称为擦除编码。这是在线完成的，因此不需要后处理。擦除编码将RAID5/6条带分布到多个主机上，没有任何开销或数据局部性需求。RAID-5需要至少4个主机集群，具有 3+1 逻辑，并且必须在不丢失数据的情况下承受一个节点故障。这减少了磁盘容量消耗。擦除编码可以保证容量减少。此策略可以使用 SPDM 系统在单个虚拟机磁盘（VMDK）文件/磁盘上执行。

摘要

vSAN 性能和健康服务有助于对已知问题进行更新的健康检查，并为最终用户提供可见性。它不会帮助用户从客户站点收集日志并将它们发送以供支持，以便开发团队在最终用户提交支持票据后获得事件。相反，它有助于数据，这些数据有助于工程团队增强 VMware 产品和相关服务，解决问题，并在实施 VMware 解决方案时推荐最佳实践。

在下一章，第三章，使用 Workspace One Intelligence 进行安全，我们将了解客户如何越来越受到压力，需要提供更多关于其组织和用户行为的智能洞察，以提供最佳的 IT 服务。拥有不同工具和系统，这些系统在移动设备管理（MDM）、PC 和其他第三方系统中存储这些有洞察力的数据，导致数据碎片化，以及训练过程中的不一致性，以及最终用户体验。

进一步阅读

• VMware Virtual SAN 设计和规模指南，在www.vmware.com/files/pdf/products/vsan/VSAN_Design_and_Sizing_Guide.pdf

• VMware Virtual SAN 健康检查插件指南，在www.vmware.com/files/pdf/products/vsan/VMW-GDL-VSAN-Health-Check.pdf

• vSphere 6.0 配置最大值指南，请参阅www.vmware.com/pdf/vsphere6/r60/vsphere-60-configuration-maximums.pdf

• 来自 VMware vSphere 文档中的 vSphere Storage 指南的 Virtual SAN 文档，请参阅www.vmware.com/support/pubs/vsphere-esxi-vcenter-server-pubs.html

• VMware Virtual SAN 部分，来自 VMware vSphere 6.0 性能最佳实践的文档，请参阅www.vmware.com/files/pdf/techpaper/VMware-PerfBest-Practices-vSphere6-0.pdf

• 针对网络性能不佳的解决方案，来自 vSphere Monitoring and Performance vSphere 6.0 部分，请参阅pubs.vmware.com/vsphere-60/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-60-monitoring-performance-guide.pdf

第三章：使用 Workspace ONE Intelligence 的安全性

本章将详细讨论 VMware Workspace ONE 及其创新的方法来保护应用程序、数据、端点和网络。它可以通过其智能分析引擎管理应用程序和设备的访问权限，并通过集成第三方工具为最终用户提供端到端的安全保障。

我们将学*如何通过高级分析来保护客户的数字工作空间，以及如何创建智能策略来检测、保护和修复他们的应用程序免受威胁。我们还将学*如何设计一个符合客户政策和 Workspace ONE Intelligence 用例的解决方案。

本章我们将涵盖以下主题：

• Workspace Intelligence 概述及其商业目标

• 集成深入洞察、智能规划和智能自动化

• 概念和逻辑设计要求

• Workspace Intelligence 的用例

• Workspace ONE Intelligence 信任网络和 Workspace ONE AirLift 概述

技术要求

您可以下载 VMware Workspace ONE Intelligent Hub my.workspaceone.com/products/VMware-Workspace-ONE-Intelligent-Hub

Workspace ONE Intelligence

Workspace ONE Intelligence 具有利用 Workspace ONE 平台的能力，通过基于数据的行动和单一存储库的解决方案来更好地解决问题。用户希望在任何设备上从任何地方访问他们的企业数据和应用程序。在当前环境中，安全工具无法以主动的方式处理最终用户的需求和安全风险。由于始终变化的边界（最终用户设备的地理位置）导致巨大的网络安全威胁并复杂化管理任务，客户无法完全了解设备、应用程序和用户数据。

每个组织都必须照顾好他们的员工，同时不妥协安全。员工的生产力会受到应用程序执行问题和服务的非正常运作的影响。频繁更改应用程序访问权限会通过降低权限来影响它。我们必须找到一种方法来绕过安全和用户的生产力，通过使用智能数据分析自动化来避免复杂的管理流程。我们还需要一个解决方案来应对频繁变化的威胁领域，该解决方案可以与所有相关服务集成，并在当前的数字工作空间系统中提供安全方面的保障。

Workspace ONE Intelligence 是建立在 Workspace ONE 平台之上的云服务，它通过提供出色的图形、用户界面工具和智能流程，帮助客户从单一的真实来源做出数据驱动的决策。Workspace ONE Intelligence 通过收集、检查和连接设备、应用程序和用户数据，按需过滤和查找关键绩效指标（KPIs）。一旦获取所需的数据信息，它就可以利用内置的规则引擎来自动化基于广泛指标的策略。客户可以定义规则，根据上下文进行智能修复操作。可以采用 AI 和 ML 技术来建议行动和为整个数字工作空间系统进行未来规划，而不会影响最终用户的生产力。

移动云时代的网络安全需要一套全面的 企业安全策略和方法。Workspace ONE Intelligence 合规引擎持续监控设备并执行升级操作，以防止违规行为。

Workspace ONE Intelligence 的业务目标

Workspace ONE Intelligence 将帮助客户处理以下业务目标：

• 它帮助管理员在应用程序部署的不同阶段获得端到端可见性，从与地面上的最终用户进行应用程序互动并获得良好响应，到快速解决问题、最小化支持电话和提升用户生产力。

  以下截图显示了从单一控制台提供的端到端可见性：

• 它通过提供用户所需的内容并降低硬件和软件的资本支出（这些支出随着洞察力对资源利用率的可见性而减少），帮助组织更好地利用资源。

• 它可以通过识别不合规的系统并自动基于最终用户行为自动化访问控制规则，使用当前的安全补丁快速找到并修复所有类型的漏洞。

Workspace ONE Intelligence 通过利用 Workspace ONE 平台，在三个重要领域提供帮助。

集成深度洞察

集成洞察意味着能够全面了解客户的数字工作空间，并拥有细粒度的洞察力，这些洞察力有助于数据驱动的业务策略：

• Workspace ONE Intelligence 将所有硬件（系统）、应用程序和最终用户数据在单一平台上相互结合和连接，以获得对数字工作空间系统的全面可见性。

• 客户可以实时做出决策，解决最终用户的问题，并避免所有安全风险。

• 客户可以运行或定义定制报告，以基于历史数据获得验证数据，并将这些洞察力用于与其他相关决策。

• 根据他们的业务需求，客户必须保持对其关键数据的投资。他们可以积极思考所有即将出现的安全漏洞、应用路线图、硬件注册、应用生命周期以及未来的补丁时间表。

客户可以从一个控制台看到完整的数字工作空间系统，包括搜索和查询系统以分析数据、识别模式、检测异常行为的能力。他们可以使用预定义的仪表板和过去的数据，为完整的系统做出基于准确数据决策。

我们将获得与以下属性/参数相关的关键信息：

• 应用生命周期

• 应用消耗

• 应用承诺

• 用户承诺

• 设备类型

• 操作系统部署

• 应用描述

• 应用订阅

客户可以运行报告以查找存在补丁漏洞的系统，监控整个系统中的关键 Windows 安全状态，包括监控应用发布的安装阶段，或在 Workspace ONE Intelligence 平台上获取软件和设备清单。

智能规划的应用分析

客户可以更好地利用整个环境中的软件开发生命周期，并快速解决事件，最小化支持电话，并增强最终用户的使用便捷性。

智能商业分析以实现最大生产力：

• 客户可以看到实时应用操作，这有助于他们立即对为最终用户造成问题的议题做出决策。他们可以先解决所有关键问题，然后根据最终用户的需求定义应用升级时间表。我们可以通过在系统、地理边界、连接状态或应用版本层面全天候监控应用利用率，获得应用过程的 360 度视图。客户可以获取有关各种用户群体应用消耗的详细分析，包括所有相关数据。

• 客户可以在其系统中量化应用消耗和使用情况，并识别最常使用和易于计算投资回报率（ROI）的应用。这将帮助决策者更好地理解移动性如何通过从应用部署的每个阶段到端到端的可见性帮助最终用户。

• 客户可以在其应用中找到关键流程或操作，并将它们与重要的业务参数相关联。

• Workspace ONE Intelligence 的客户可以为其自建应用获得自动化的好处。

Workspace ONE Intelligence 协助基于策略的应用部署。策略通过推荐上下文作为参数定义，通过检测问题的根本原因来监控应用性能，并通过所需和测试过的补丁来增强应用交付。

Workspace ONE Intelligence 的价值主张如下：

• 资产生命周期更新的准确计划

• 应用许可更新和升级

• 操作系统第一天支持

• 定制设备和应用程序配置

• 根据工作领域定义安全策略基线

由决策引擎驱动的智能自动化

客户可以通过自动化定义的工作流程利用决策引擎来提高组织内的利用率：

• 客户可以配置预定义的自动化，以智能方式管理数字工作空间。

• 客户可以通过创建基于这些策略中配置的参数触发的策略来自动化操作和安全流程。基于上下文的策略通过避免手动工作来提高自动化过程。

• 客户可以构建与上下文相关的修复流程规则，以帮助自动化，从而提高最终用户的生产力和易用性。

• 客户可以创建基于上下文的规则，这些规则与客户环境相关，并通过自动化工作流程，这些工作流程可以集成通过 REST API 与第三方应用程序（如 ServiceNow 和 Slack）。

Workspace ONE Intelligence 通过创建基于多个指标的自动化移动规则，在系统中拥有智能任务引擎。它将有助于根据安全策略构建上下文工作流程，以进行智能修复移动，并确保合规性。Workspace ONE Intelligence 可以与第三方 API 层集成，创建可以利用客户特定要求的工作流程，如下所示：

• 检测具有高安全威胁的动作，并获得所需的访问控制，而无需任何手动干预

• 智能应用程序发布周期可以在部署前检测问题

• 通过自动化数据发现来定义所需的系统状态

• 集成第三方应用程序来自动化业务任务

自动化工作流程利用第三方服务以避免应用程序安装失败。

设计要求

客户必须实施企业级计划，以通过移动设备为用户提供灵活且强大的企业系统访问权限，如下所示：

• 从任何设备、任何地点为员工提供安全的移动电子邮件访问

• 向特定员工提供安全内容，以增加现场工作效率

• 为中央 IT 提供一层安全和监督，并确认企业系统访问是以预期和可信的方式进行

在确定适当的设计解决方案时，设计元素可能有多个选项。在这种情况下，以下按优先顺序排列的设计质量用于确定最佳设计解决方案：

设计质量优先级****（从高到低考虑）	描述
可用性	实现高可用性操作的能力
可管理性	灵活性、可扩展性和易于操作
性能	环境的性能
恢复性	从影响可用性的意外事件中恢复的能力
安全	整体基础设施安全以及符合监管政策

概念设计

VMware 平台为客户由多个相互连接的层组成，每个层都提供功能以满足业务需求。我们将在以下图表中详细说明每一层：

每个单独的层都提供特定的功能，以提供整体最终用户计算解决方案：

• 用户访问：这是所有移动应用程序和资源的单一接口

• 应用资源层：这些是向用户提供应用资源的必要组件

• 桌面资源层：这些是向用户提供设备资源的必要组件

• 虚拟化层：应用程序在虚拟机上的管理程序上托管

• 物理层：这是运行工作负载所使用的物理基础设施

除了水平层之外，还有两个垂直层与五个水平层中的每一个交互：

• 管理：管理已配置基础设施所需的组件

• 安全：用于确认已配置的工作负载和基础设施符合客户定义的策略的组件

以下项目被确定为工作环境的关键业务驱动因素：

业务驱动因素	描述
安全	确认未管理的设备无法访问企业系统
员工效率	为员工提供对企业系统的移动访问
成本节约	通过减少基于移动性的 IT 硬件支出来实现成本节约

我们现在将讨论水平层：

• 用户访问：用户门户提供了用户开始的一致接口。门户核心功能如下：

  • 企业应用单点访问：这是用户能够从目录中选择项目，并按需快速部署、修改或退役的能力

  • 自适应注册：这是基于请求的应用程序的安全状态进行的设备注册

以下图表详细描述了各种业务驱动因素及其用例：

• 应用资源层：应用资源层向用户提供应用资源。这些资源包括以下内容：

  • 基于云的应用

  • 第三方应用

  • 内部应用

  • VPP 应用

• 设备资源层：设备资源层提供以下功能：

  • 设备配置与配置文件

  • 移动电子邮件管理

  • 应用特定配置

  • 移动内容管理

• 虚拟化层和物理层：虚拟化层在虚拟机中托管所有应用程序。物理层为 AirWatch 企业移动管理（EMM）平台提供物理组件。以下包括以下内容：

  • 设备：呈现给用户的物理设备

  • 服务器：托管虚拟化工作负载的物理服务器

  • 网络：包括交换机、路由器和 WAN 链路在内的物理网络基础设施，这些是各种组件互连所需的

• 管理与监控：由于终端用户平台动态性的原因，管理是一个关键组件。管理垂直层与平台的所有五层交互，以实现整个堆栈的管理效率和主动性。垂直管理提供以下组件：

  • 库存管理：从单个管理界面管理和查看设备的能力

  • 报告功能：报告一组设备或配置的能力

  • 设备命令：根据需要向用户设备推送命令的能力

• 安全：安全垂直层与所有层交互，以实现满足安全要求。安全垂直层提供以下内容：

  • 合规性规则：确认设备是否按预期行为的能力

  • 对企业系统进行安全访问：确保对企业系统（电子邮件、内容和数据服务器）进行安全访问的能力

本节在概念设计的基础上，通过添加作为解决方案核心的逻辑组件来构建。逻辑设计反映在以下图表中，以下子节讨论每个组件：

本节从高层次讨论构成前面图表设计的逻辑组件：

• 用户访问

  • VMware AirWatch 提供了所需的注册和数据流程，以提供统一的用户访问状态。

  • VMware Identity Manager 提供身份验证策略，并查询现有的身份验证源以进行授权。客户利用VMware Identity Manager根据用户的网络来源执行多因素身份验证。一旦身份验证成功，VMware Identity Manager向用户提供其可访问资源的目录。

• 应用程序资源层

  • 基于云的应用程序（软件即服务（SaaS）模式）在VMware Identity Manager门户上配置并呈现为目录项。访问客户门户的用户从他们的目录中选择应用程序。

  • 第三方应用程序是在特定操作系统应用商店中可用的应用程序，例如 iOS 应用商店和 Google Play 商店。

  • 内部应用程序是指客户内部开发的应用程序。VMware AirWatch 允许管理员直接将这些应用程序推送到设备。

  • VPP 应用程序是通过 Apple 批量购买计划购买的。

• 设备资源层

  • 基于 XML 的配置文件：VMware AirWatch利用基于 XML 的配置文件来强制实施限制并推送配置。

  • SEG/PowerShell：客户将利用SEG/PowerShell来确保其端点运行的邮件应用程序的移动访问安全。该系统利用邮件合规性规则，为管理员提供对移动电子邮件访问的可见性，并启用一致的设备安全状态。

  • 应用配置：VMware AirWatch与应用配置**标准集成，允许针对特定用例进行应用程序特定的配置。

  • AirWatch 隧道：VMware AirWatch 隧道确保对企业系统（如内部网站）的访问安全。

• VMware AirWatch 内容锁：这确保了对后端内容源的访问安全。该服务器组件确认只有注册的、安全的设备才能访问敏感的内部数据。

• 移动设备：以下设备平台已被客户选中：

  • Apple iOS

  • Android

  • Windows 10

• 网络：本系统使用现有物理网络。详细的网络连接在 VMware Workspace ONE 设计和部署服务工程规范中概述。

• 虚拟机：本系统使用现有的虚拟机基础设施。

Workspace ONE Intelligence 的前十大用例

Workspace ONE 消除了访问云、移动和 Windows 应用程序的猜测。IT 可以放心，无论是自带设备（BYOD）还是企业拥有的设备都是安全的，并且可以通过简单易用的条件访问设置来保护网络。管理者无需担心员工的生产力，因为安全的应用程序，包括邮件、日历、文档和社交媒体，都能确保员工的工作不间断。并且，员工通过实时应用程序交付和自动化永远不会错过任何一点。

识别和缓解移动操作系统漏洞

客户挑战：发现已知漏洞，如 Spectre 或 Meltdown。每个制造商都迅速发布操作系统更新，但制造商在实施修复方面的做法各异。每个操作系统都有自己的更新计划和版本；iOS 使用操作系统版本，而 Android 使用安全补丁。IT 管理员无法确定受影响的移动设备并在整个环境中部署修复。

Workspace ONE Intelligence 可以帮助快速评估和报告威胁或漏洞的影响，并将这些报告与组织内的管理层和 IT 团队共享。它通过创建所有设备中具有过时操作系统版本（iOS）或旧安全补丁日期（Google）的视觉表示，轻松识别具有已知漏洞的资产。它通过组织组、设备类型或型号对数据进行分段，以查看哪些设备过时程度最高且最易受攻击。它利用自动化来针对易受攻击的设备，并添加强制操作系统更新（仅限 iOS 受监督设备）的操作，通过电子邮件或 Slack 通知最终用户，通知最易受攻击设备的 InfoSec 团队，将设备移动到具有更严格访问要求的组织组，并监控 Android 和 iOS 上已修补或升级的设备数量。

主要优势：这提高了组织内的安全卫生，增加了合规性，并增加了 IT 运营和 InfoSec 团队之间的协作。

Windows 10 操作系统更新和补丁的洞察

客户挑战：客户请求一个列表，列出没有安装特定 KB 的设备，这些设备风险最高（严重安全或关键 Windows 更新）。

Workspace ONE Intelligence 可以帮助客户为所有当前没有安装关键 KB 的设备创建实时仪表板，并可以通过型号或操作系统版本对数据进行隔离，以识别具有风险的操作系统版本。自动化将帮助通知用户其设备的所有更新，并将监控所有 Windows 10 设备是否已修补或升级。

主要优势：客户可以节省时间，提高用户体验，并更好地保护他们的端点。

预测 Windows 10 戴尔电池故障并自动化更换

客户挑战：用户正在使用需要全天充电的 Windows 端点，这有时会影响最终用户的生产力，因为它们限制了他们的移动性。

Workspace ONE Intelligence 可以通过限制这些用户的移动性来帮助他们。客户需要一个能够监控电池健康不佳的 Windows 10 戴尔设备以及电池整体寿命报告或仪表板的解决方案。它应该向最终用户提供关于电池寿命的可见性。众所周知，随着电池寿命的减少，最大充电容量会降低。它可以在 Workspace ONE UEM 中创建一个工作流程，为电池寿命不佳的设备添加标签。它还将帮助报告，并创建带有设备信息的 ServiceNow 工单以订购新电池。然后，它将通过自动化所有手动任务，通过 Slack 或电子邮件通知员工更换电池。

主要优势：自动化将减少与用户生成支持工单或电话相关的成本，并通过延长设备使用寿命来提高员工体验和生产力。

识别不受支持的操作系统版本和平台

客户挑战：对于 IT 来说，一个重大挑战是了解有多少用户拥有组织不再支持的设备，这些设备可能存在安全风险。对于 IT 来说，另一个挑战，特别是对于正在构建自己应用程序的组织来说，是缺乏对组织内设备和操作系统分布的可见性。

Workspace ONE Intelligence 可以帮助识别那些无法升级到最新操作系统且面临最新安全威胁的旧设备，并在仪表板上创建报告或小部件，以识别潜在的淘汰候选设备。它提供了用户中最受欢迎的设备类型的可见性，向员工推荐新硬件，并轻松地将设备和操作系统版本采用情况传达给应用开发者，以确保他们为最受欢迎的设备/操作系统组合构建，并最大化其内部应用程序的采用率。它根据使用情况快速确定哪些设备和操作系统版本将停止支持。

主要优势：这可以优化开发工作，按地理区域了解用户需求，节省时间，并提高生产力。

跟踪操作系统升级进度

客户挑战：每年，苹果和谷歌都会发布新的主要操作系统更新，这些更新包括新的 UEM 功能以实现更好的管理，以及管理员希望其最终用户掌握以提高生产力的新可用性功能。当发布主要操作系统时，管理员需要*乎实时的可见性，了解操作系统版本被采用的情况，以便他们可以预测他们需要试点新功能的时间有多长，以及确定部署新 UEM 功能（例如，安全策略）到所有设备的好时机。

Workspace ONE Intelligence 可以帮助创建仪表板来监控旧版和新版操作系统的采用情况，同时监控报告最新操作系统版本的设备数量的增加，以及报告先前版本的设备数量的减少。它还逐年比较不同供应商的操作系统采用情况，并预测主要操作系统发布将何时达到其大多数设备。

主要优势：这有助于就整个环境做出明智的决定，为应用开发者提供定量洞察，并根据操作系统分布优先考虑功能开发。

监控设备利用率或使用情况

客户挑战：在商业用例中，设备具有单一或多用途，它们要么由一组用户共享，如在零售店，要么专门为一名用户使用，例如航空公司的电子飞行包。在两种情况下，IT 都需要可见性来确保所有这些资产都处于在线和活跃状态。在零售业，设备不活跃的商店很可能是被盗。航空飞行员没有设备就无法飞行，因此应该几乎没有不活跃的设备。

Workspace ONE Intelligence 可以帮助 IT 团队了解哪些商店的设备最不活跃以及它们的位置，并使用自动化通知商店经理可能被盗的设备。它还可以创建工单（ServiceNow）并将需要更新的设备部署到正确的位置，并使用仪表板监控组织或每个地点最常用的设备类型。它还使用智能在购买新设备时做出数据驱动的决策。

主要优势：这有助于提高商店性能，提高组织内的效率，并优化资源。

提高 Windows 10 设备的合规性

客户挑战：IT 团队必须协作，快速识别 Windows 10 PC 在任何时刻的设备状态。他们必须安装多个代理来获取基本的操作系统和型号信息，或者报告更细粒度的设备状态，如 BIOS 版本和安全启动状态。

Workspace ONE Intelligence 可以帮助只需要一个代理来收集和报告 IT 团队关心的所有众多设备状态，并了解高风险设备。查询整个环境以识别最危险的设备，如过时的 BIOS 版本、安全启动禁用、TPM 芯片禁用、防火墙禁用、防病毒软件禁用和 BitLocker 加密的笔记。它可以按操作系统版本、地区和型号对这些设备进行排序和分段，并创建自动隔离高风险设备以及移除对敏感数据源访问的规则。它通过推送安全策略来执行自动化，以加强合规性：移除对 VPN/Wi-Fi 的访问、重新启用 BIOS 设置，并将设备移动到拥有较少权限和应用程序访问权限的组织组。

主要优势：这可以节省时间，因为不需要从不同来源汇总多个报告；提高整个环境的合规性；并提高 IT 运营效率。

综合移动应用程序部署可见性

客户挑战：作为一名 IT 管理员，部署应用程序更新对于满足业务和安全需求至关重要。有时，部署应用程序的机会非常有限。在零售业，只能在午夜进行；对于安全来说，越快越好；而对于 24 小时医疗工作者来说，可能没有合适的时间推送更新。

Workspace ONE Intelligence 可以帮助根据使用模式确定部署应用程序的最佳时间，并准确报告部署进展情况。它还向应用开发团队、管理层和帮助台提供任何应用程序的全方位视图，以实时提供有关应用程序采用和参与度的信息。它通过快速检测部署问题或应用程序采用不佳的根本原因，深入了解每个设备制造商、型号或操作系统版本的应用程序性能。旧版应用程序的设备可以收到更新到最新版本的提醒，当用户基数较低时，应用程序开发者可以停止维护旧版本。它利用自动化操作来修复问题，例如，如果新版本不稳定，则通知商店经理重新部署应用程序的先前版本。

主要优势：这可以减少与用户生成支持工单或电话相关的成本，并提高员工体验和生产力。帮助开发者优先考虑功能，并深入了解可以退役的旧版应用程序。

跟踪生产力应用程序的迁移和采用情况

客户挑战：IT 部门通常会根据用户反馈和许可成本评估生产力应用程序，并经常将最终用户从一种生产力应用程序迁移到另一种。IT 部门的挑战在于了解迁移的进展情况以及用户是否正在采用新的生产力应用程序，以达到淘汰旧解决方案的目标，例如，从 WebEx 迁移到 Skype 再到 Zoom。

Workspace ONE Intelligence 可以帮助快速确定哪些设备安装了哪些生产力应用程序，并监控每个应用程序在每个位置或组中的普及率。它确定一个位置或组是否已完成对新应用程序的迁移，并根据使用和采用情况使用自动化通知用户需要迁移到新应用程序。它根据使用模式确定部署应用程序的最佳时间，并准确报告部署进展情况。它还向应用开发团队、管理层和帮助台提供任何应用程序的全方位视图，以实时提供有关应用程序采用和参与度的信息。它通过快速检测部署问题或应用程序采用不佳的根本原因，深入了解每个设备制造商、型号或操作系统版本的应用程序性能。旧版应用程序的设备可以收到更新到最新版本的提醒，当用户基数较低时，应用程序开发者可以停止维护旧版本。它利用自动化操作来修复问题，例如，如果新版本不稳定，则通知商店经理重新部署应用程序的先前版本。

主要优势：这可以优化资源，降低风险，提高合规性，提高员工体验，并提高 IT 运营效率。

采用内部移动应用程序

客户挑战：组织在构建和维护内部应用程序上投入了大量资金，但他们无法了解有多少应用程序被使用以及如何使用。

Workspace ONE Intelligence 可以帮助业务线（LOB）所有者轻松监控他们负责的应用程序的使用和参与度，并可以使用应用详细仪表板中可用的实时和历史数据优先考虑功能开发。它轻松确定为什么应用程序未被使用，并排除任何性能或兼容性问题。强制使用的最少使用应用程序可以采取采用补救行动计划；那些非关键的应用程序可以被淘汰，资源可以重新分配到更重要的项目上。

主要优势：这将优化资源，提高用户体验，提高生产率，并最大化开发者的努力。

Workspace ONE Trust Network

Workspace ONE Trust Network 为顾客提供了一种广泛且新的安全方法来保护他们不断发展的数字工作空间。顾客可以创建符合要求的跨组织安全流程，从员工、应用程序、端点和网络，利用新功能来防御、识别和恢复基于信任和验证框架的网络安全风险。

Workspace ONE Trust Network 内置了在 Workspace ONE 平台上开发的安全功能，它们与第三方安全合作伙伴服务集成，以在整个数字工作空间提供安全保护。

Workspace ONE Trust Network 提供以下服务：

• 客户可以配置数据加密和应用黑名单的规则。它可以监控威胁，例如恶意软件和恶意应用，并通过其类似访问控制的特性来帮助修复。

• 最终用户可以利用自助应用程序目录和单点登录到应用程序，以提高效率和跨所有应用程序的多因素身份验证，这将有助于应用程序保护。

• 它有助于对安全威胁进行端到端监控，例如操作系统漏洞、身份验证问题和基于应用程序的攻击。它可以通过在短时间内擦除、隔离和打补丁来自动化对风险的应对措施。

• 它可以通过隔离和修复根本原因来识别可疑的应用程序或文件以及攻击。

• 它具有数据丢失预防组件，具有端到端可见性，并使用其数据分析引擎防止未经授权的数据传输。

我们将通过数据分析获得有价值的数据，并通过自动化数据过滤来避免验证和检查过多数据。

数字工作空间是一个创新领域，通过将第三方安全工具与 Workspace ONE 集成，提高了最终用户体验。

Workspace ONE AirLift

Workspace ONE 可以通过基于云的服务、智能数据分析自动化提供端用户设备生命周期管理任务。VMware 数字工作空间是唯一适用于所有用例和端点设备不同阶段的统一端点管理解决方案。

Workspace ONE 可以通过以下功能帮助客户转换 Windows 10 管理：

• 客户可以通过零接触入职（Zero-Touch Onboarding）为新员工提供第一天的工作效率，并提高生产力。

• 客户可以通过云驱动的策略实时配置，从固件到操作系统/应用程序层。Workspace ONE 可以与 Dell Client Command Suite 集成，以实现空中 BIOS 配置。

• Workspace ONE Intelligence 可以在客户网络实时或离线打补丁，确保它们始终保持最新并受到高严重性漏洞的保护。

• 这是一个完全基于 Web 的解决方案，具有对等 Win32 应用程序分发，无需服务器占用。

• 它具有与 Microsoft 系统中心配置管理器 (SCCM)的 AirLift 共管理和共存功能，通过协助任何PC 生命周期管理 (PCLM)任务，同时也支持使用 Windows 10 版本的当前 SCCM 部署。

Workspace ONE 平台更新

客户正在使用多个平台，如 Windows 10 和 macOS，因此他们需要在所有平台上进行定期和安全的应用程序交付。Workspace ONE 为所有应用程序提供安全、生命周期管理和引人注目的功能，无论操作系统平台如何，无论是在移动端还是桌面端。这些功能帮助 IT 团队以最大可用性提供更好的安全性。

扩展 Win32 应用程序交付

即使大多数组织正在采用操作系统中立的应用程序，Windows 应用程序仍然是任何数字工作空间的重要组成部分。Workspace ONE 从单个控制台结合了应用程序和桌面配置，该控制台托管在本地私有云或云服务提供商（公共云）中。VMware Horizon Cloud on Microsoft Azure VDI 是 VMware 对 Microsoft Azure 上发布的应用程序支持的扩展。

客户可以使用 VMware 软件定义数据中心工具（如 NSX、虚拟存储区域网络 (vSAN)和 vSphere）管理本地桌面和应用程序到云，跨越亚马逊数据中心网络，超越区域边界。他们可以利用 Horizon 7 云 Pod 架构 (CPA)跨 AWS Pod，以单个 Horizon 7 管理控制台支持跨本地和基于云的基础设施的用户源，进行日常操作。

简化的 macOS 采用

Workspace ONE 的 macOS 客户端为用户提供了一个统一的平台，即使用户将迁移到不同的操作系统平台。用户可以从 macOS 上使用所有应用程序，包括虚拟 Windows 应用程序。

扩展 Microsoft Office 365 (O365)应用程序的安全性

Workspace ONE 将 Intune 应用保护规则扩展到 Microsoft Graph，以提供 IT O365 特定的安全功能，例如数据丢失预防控制和持续设备风险监控，如果检测到威胁，则会动态断开 O365。客户将确保关键业务数据的安全，因为他们的最终用户正在使用 Office 365 进行日常使用，这可以轻松地与其他关键应用程序集成。

带有智能工作流的 VMware Boxer

客户可以使用由基于上下文的移动和 VMware Boxer 安全电子邮件中的准确理解驱动的移动流，帮助他们的最终用户在移动设备上管理内容。用户可以在 Boxer 应用程序中，通过自动化工作流，在多个后端业务流程（如 Salesforce、Concur 和 Jira）中完成工作。他们拥有带有自动化工作流功能的 Boxer 工具，可以设计预定义的连接器与第三方服务，以帮助用户在 Boxer 中提高生产力。

坚固型设备的扩展管理

坚固型设备需要在现场进行远程管理和智能修复，这两者对于实现最大可用性都至关重要。Workspace ONE 通过支持 Android 设备的电池管理，帮助客户实现最大化的正常运行时间。客户可以修复一个定义明确的条款，例如电池或内存级别、网络连接性，或触发特定操作的时间，例如强制退出关键任务应用程序或备份文件。

客户可以从坚固的设备中检索电池健康、循环计数和识别信息，以识别不良电池并在其表现不佳之前更换它们。

Workspace ONE 已开发了一个广泛的 API 框架，该框架与现有的企业系统和服务以及第三方应用程序集成。Workspace ONE API 框架允许外部程序调用核心 Workspace ONE 产品功能，扩展安全措施并加强整体企业基础设施。Workspace ONE 架构集成了 RESTful 和Windows Communication Foundation（WCF）Simple Object Access Protocol（SOAP）企业 API，以实现自动化、实时事件通知到集成解决方案。

摘要

Workspace ONE Intelligence 具有智能统一端点管理功能，可提供对数字工作空间的深入理解，并支持自动化交付。客户可以通过这些功能增强其安全性、合规性和最终用户的生产力。Workspace ONE Intelligence 协助基于数据的决策，通过数字工作空间分析提供数字工作空间系统中的所有关键数据信息。

没有任何工具，仅凭大量数据聚合来管理移动工作环境是不可能的。在没有所有设备、应用程序和最终用户可见控制台的情况下，在数字工作空间中进行数据驱动的决策是一项艰巨的任务。手动任务是对用户需求和外部行为的被动反应，而不是主动的。

在下一章中，您将了解 VMware 如何通过将其 VMware vRealize Suite 组件中的高级分析注入到其客户的数据中心以及运行在 vSphere 上的公共云中，从而帮助客户自动化数据中心和公共云，以基于意图管理 IT 运营。

第四章：使用 VMware vRealize Suite 进行主动操作

在本章中，我们将关注 VMware 如何通过将高级分析注入解决方案，以意图为基础管理 IT 操作，帮助客户自动化基于 vSphere 的数据中心和公有云。vRealize Operations 的容量分析引擎利用机器学*技术，根据过去趋势分析主动提醒您关于未来事件。

我们将了解 vRealize Suite 中的不同分析引擎，以及 vRealize 工具如何在不同的云环境中工作。此外，我们还将学*通过降低总拥有成本（TCO）来在 vSphere 上自动化容器，并通过更好的优化提高投资回报率。

本章我们将涵盖以下内容：

• 统一端到端监控

• 软件定义数据中心（SDDC）之旅中的智能操作分析

• vRealize Operations 架构和容量规划

• VMware 容器管理服务

• VMware Cloud on AWS 的实施计划

技术要求

请参阅此链接了解 VMware Cloud on AWS cloud.vmware.com/vmc-aws。

统一端到端监控

监控解决方案应收集和监控端到端的服务级别和基础设施级别的关键绩效指标（KPI），例如事务响应时间和服务可用性，并对偏差发出警报。它可以理解和映射端到端服务的所有组件，例如应用程序和应用程序组件，并监控所有应用程序平台组件的性能和可用性，例如 Web 服务器、应用程序服务器、消息总线数据库。我们应该通过监控所有虚拟和物理基础设施组件的性能和可用性来理解和映射所有虚拟和物理基础设施组件，包括虚拟机、服务器、存储和网络。我们可以通过识别警报的根本原因来结合和关联所有这些参数，并通过生成警报。IT 运维团队能够根据其角色在可定制的仪表板上获取所有信息，并具有所有报告功能。它应该为分析能力添加预测元素，以防止业务中断。

智能操作分析

虚拟环境的动态性和复杂性要求从整体角度出发，与应用程序和其他基础设施部分进行基本关联。它需要一种新的数据管理和分析技术（为物理基础设施设计的工具不适合虚拟环境的动态和去中心化特性）。

操作分析包括两个关键领域：

• 性能分析帮助客户通过以下方式在 IT 操作中采用主动方法，以实现更快的问题检测和解决：

  • 基于自动学*、*实时基准调整、统计和趋势算法的主动控制服务性能和可用性

  • 服务影响分析和优先级排序

  • 问题隔离和根本原因分析

• 容量分析通过当前和历史数据分析、模拟以及实现假设情景的能力，实现预测方法：

  • 中长期配置的容量规划和预测

  • 预测警报

  • 通过自动化配置和扩展实现*实时的容量优化

vRealize Operations Manager 架构

vRealize Operations Manager 收集和分析企业内部多个数据源的信息。vRealize Operations Manager 使用高级分析算法来学*和识别它所监控的每个对象的正常行为。这些信息通过视图、报告和仪表板呈现给用户。

用户界面允许用户以徽章、警报、图表和报告的形式访问分析结果。

vRealize Operations Manager 可以作为虚拟设备（vApp）下载并作为 VM 运行。它将被配置为在完整的 vRealize Operations Manager 集群设计中执行以下角色之一：

• 主节点：集群中的关键第一个节点，或者在小型部署架构中将是单个独立节点

• 主副本节点：用于高可用性的可选实例

• 数据节点：用于可扩展性目的

• 远程收集节点：有助于克服数据收集问题，例如网络中的网络性能不佳

vRealize Operations Manager 提供两种不同的部署模型：

• 预配置的 vApp

• 作为 Windows 或 Linux 可安装包

客户可以选择 vApp 模型以简化部署。

应用架构概述

我们将了解 vRealize Operations Manager 的逻辑节点架构及其所有功能：

HTTP 服务是主要的产品 UI。它支持主要产品 UI、管理员 UI 和套件 API。这解释了 vRealize Operations Manager 如何计算压力，以及压力是如何用于推荐大小、剩余容量和剩余时间的容量规划计算的。这提供了足够的细节，让人们可以理解 vROps 如何计算这些值，可以在它们合理时进行辩护，可以识别出数据异常导致应被推翻的建议，并解释了 vROps 中可调整参数背后的概念。

容量规划

压力是衡量过去一个月最糟糕时刻因规模不足而导致的性能问题严重程度的指标。这是一种处理需求高峰和波动的智能方式，它考虑了资源运行的热度和连续期间运行的时间。

总容量与可用容量：总容量是原始容量。可用容量是我们为了规划目的而假定的容量，考虑到宿主故障并减去一些安全余量以确保安全。

总容量 – 缓冲区（高可用性和通用）= 可用容量。您可以在 vROps UI 的“分析 | 剩余容量”中看到这一点。

容量定义了压力区域。对于压力计算，我们是使用总容量还是可用容量？这取决于我们是否想了解实际发生了什么（总容量），还是我们正在为未来规划并希望更加谨慎（可用容量）。

对于实际的压力计算，我们使用总容量作为容量。在规划和寻找建议的合适规模时，我们希望谨慎行事，因此我们进行压力计算，其中容量是可用容量，考虑到可能的宿主故障和一些安全余量，在什么容量下我们几乎避免了性能问题，而没有浪费资源。

关键成功因素

以下为关键成功因素：

• 提高平均修复时间（MTTR）和运营效率，以防止严重的服务影响

• 实施统一的端到端监控

• 将持续容量和性能管理与基于策略的自动化修复相结合，以动态优化性能和容量使用，并迅速修复性能问题

• 引入运营分析以增强实时可见性，并提供基于基础策略的自动化修复能力，用于问题隔离和故障排除

• 通过警报和改进平均故障间隔时间（MTBF）以及高级主动和自动化能力来引入主动问题检测

• 实现对容量、性能和可用性的全面主动控制

• 采用预测分析能力以实现主动问题识别和解决

• 日日常性能、容量和可用性问题主要是由自适应流程自动化管理的

VMware 的 Kubernetes 解决方案

Kubernetes 是企业采用的容器编排器，但将 Kubernetes 运行在生产环境中并非易事。企业需要一个支持多云环境并具有网络服务、安全、策略、持久性、监控和数据分析的全面解决方案。随着容器使用量的增加，客户需要编排工具来管理操作，例如扩展和缩减、调度容器和处理故障，以便运行和管理这些容器。Docker Swarm 和 Mesosphere 等容器编排工具可用，但最被接受的是名为 Kubernetes 的开源系统。Kubernetes 为运行容器化应用提供了完美的解决方案，但在生产环境中运行 Kubernetes 仍然是一项复杂的任务。生产能力（如存储、网络、安全、多租户和持久性）需要更多增强和补充工具，以可靠地部署、维护、扩展、监控和自我修复底层基础设施。

Pivotal Container Service 和 VMware Kubernetes Engine

VMware 有 Pivotal Container Service (PKS)，这是 VMware、Pivotal 和 Google 联合开发的产品，它可以在 VMware SDDC 堆栈以及公共云提供商（如 Google Cloud Platform (GCP)）上部署和管理企业级 Kubernetes。VMware PKS 帮助企业在 vSphere 和公共云上运行 Kubernetes。它极大地简化了 Kubernetes 的部署和操作，以便您可以轻松地大规模运行容器。我们可以帮助客户使用 PKS，使他们能够快速在其现有的 vSphere 环境中设置和管理 Kubernetes 服务。客户正在寻找一个简单的 Kubernetes 解决方案，通过帮助他们处理第一天和第二天的一切需求，消除设置和维护平台的长步骤。他们还要求解决方案在网络、存储、安全和多租户领域提供加固的生产能力。

VMware Kubernetes Engine (VKE) 是一款企业级 Kubernetes as a Service (KaaS) 产品，提供易于使用、默认安全且成本效益高的 Kubernetes。VKE 将首先在 AWS 上推出。

Forrester 对混合云监控和管理提供商进行了 31 项标准的评估；以下是一些：

• 必须具备跨工作负载的多云管理核心能力

• 必须支持至少 AWS、Azure 和基于 vSphere 的云

• 必须作为独立工具销售

容器作为容器为开发者提供了一个简单、轻量级且可移植的方式来打包和部署应用程序，在各种主机或云环境中。由于这些好处，预计容器在未来的几年中将呈指数级增长。容器不是一项新技术，但一家名为 Docker 的公司成功推广了这项技术，Docker 现在是众所周知的容器格式。

SDDC 旅程阶段

VMware 定义了以下 SDDC 旅程阶段：

• 成本中心：IT 作为成本中心运营。重点是通过对 IT 效率的改进，通过统一的架构和通过虚拟化基础设施来降低资本支出（CapEx）和运营支出（OpEx）。

• 服务提供商：通过提供安全、高可用性和弹性的 IT 服务来满足业务需求和服务水平要求，IT 成为服务提供商。

• 业务伙伴：通过自动化基础设施和应用的交付，IT 转型为业务伙伴，从而实现更快的交付时间，更响应的 IT 服务，并缩短上市时间。

此数据中心虚拟化和标准化的能力成熟度有三个阶段：

• 计算虚拟化、业务关键应用的虚拟化、大数据应用支持

• 软件定义存储、网络虚拟化、扩展到混合云、数据中心迁移

• 在混合、异构数据中心中进行管理

以下能力至关重要：

• 财务模型和测量：对资产及其基础设施容量成本的认识和理解

• 流程和控制：IT 流程适应了虚拟化，但主要是手工的，具有临时的跨过程集成

• 建立标准操作程序以保持操作的连续性

• 关注有限的、持续的改进

VMware 基于容器的服务

这需要以下 VMware SaaS 和第三方产品：

• 部署网络虚拟化基础（NSX-T）

• 部署和运行容器化工作负载（VMware Pivotal Container Service）

提供此服务需要以下先决条件：

• 部署 NSX-T（虚拟设备）基础：

  • 虚拟设备虚拟化 CPU 容量的最低要求（GHz）是必须提供足够的 CPU 容量来部署 NSX Manager 和 NSX Controllers

  • 虚拟设备虚拟化 RAM 容量的最低要求（GB）是必须提供足够的内存容量来部署 NSX Manager 和 NSX Controllers

  • 网络时间协议（NTP）必须设置并验证时间正确。

  • 必须配置 DNS 并测试正向、反向、短名和长名解析。

  • 必须配置共享存储。必须有足够的存储容量来部署 NSX Manager 和 NSX Controllers。

  • 最大传输单元（MTU）大小：1700（最小）

在 ESXi 上部署用于网络虚拟化的 NSX-T 和在私有云中部署 PKS

根据 VMware 标准架构在客户环境中实施和验证基于 NSX-T 的网络虚拟化解决方案。该服务包括对平台先决条件的技术验证，使用 NSX-T 部署网络虚拟化，以及为客户的功能测试。

以下表格显示了与 NSX-T 相关的所有组件的安装和配置：

规格	描述
部署和配置的 NSX Edge VM	部署并配置为传输节点的 NSX Edge VM
配置的逻辑交换机	已配置的逻辑交换机
NSX-T 层 0 逻辑路由器实例（s）	NSX 层 0 逻辑路由器提供在逻辑网络和物理网络之间使用静态或动态路由边界网关协议（BGP）对等连接的进出网关服务
VMware ESXi™ 传输节点配置的主机	准备好的 ESXi 主机，已注册到 NSX-T 管理平面，并配置为传输节点

部署 NSX-T 基础架构

基础 VMware NSX-T 部署：这包括准备工作、部署和验证 NSX Manager 和 NSX Controllers：

规格	描述
数据中心位置（s）	这意味着 NSX-T 组件的数据中心部署。
NSX Manager 实例	安装并配置了 NSX-T Manager 设备。
NSX Controllers	NSX-T Controllers 已安装并关联到 NSX Manager。对于每个 NSX Manager 实例，将形成一个包含三个 NSX Controllers 的控制集群。

部署和运行容器化工作负载

在私有云中部署 PKS：部署 PKS 平台以帮助客户创建用于提供 Kubernetes 工作负载的私有云环境。

以下表格显示了与 PKS 相关的所有组件的安装和配置：

规格	描述
将 Pivotal Operations Manager 部署到 vSphere	这意味着在单个数据中心内部署 Pivotal Operations Manager。
配置 Pivotal Operations Manager	这是指配置 Pivotal Operations Manager 实例。
安装 PKS	这是指在单个 Pivotal Operations Manager 中部署 PKS 组件。
配置 PKS	这是指在 vSphere 中配置 PKS，连接到现有的 NSX-T 对象，Kubernetes 集群规模计划，用户账户和身份验证（UAA），任务，syslog，资源配置和 stemcells。
使用 PKS 创建 Kubernetes 集群	这是指使用 PKS 命令行界面根据定义的集群规模计划创建 Kubernetes 集群。
在 vSphere 中安装和配置 Harbor 容器注册库	这意味着使用o****pen virtualization application （OVA）安装 Harbor 容器注册库实例，不进行复制，以便单个实例可以为多个集群提供服务。VMware 将协助配置 Harbor 与 Kubernetes 集群节点和其他环境之间的证书，以启用向 Harbor 推送和拉取容器镜像。
NSX-T 为 PKS 集成做准备	这意味着创建 NSX-T 对象以用于 PKS 集成。
逻辑交换机	为 PKS 管理网络和服务网络创建了逻辑交换机。
外部访问 IP 池	配置 IP 池以提供为 PKS 创建的每个 Kubernetes 集群的负载均衡地址空间。网络还将提供 Kubernetes API 访问和 Kubernetes 公开服务的 IP 地址。
IP 块	IP 块配置用于通过容器网络接口（CNI）分配地址空间给 Kubernetes pods。
NSX-T 一级逻辑路由器实例	这些是一级逻辑路由器，一个专门用于 PKS 管理组件，另一个专门用于 Kubernetes 集群节点。
PKS 和 NSX-T 集成	这意味着在 vSphere 上配置 PKS 以与 NSX-T 集成。

VMware Cloud on AWS

VMware Cloud on AWS 是一个基于 vSphere 的云服务。该服务将 VMware 企业级 SDDC 软件带到 AWS 云中。它由 VMware 提供、销售和支持，作为一个按需、弹性可扩展的服务，利用 AWS 的全球足迹和服务范围。

除了 VMware vCenter Server®管理和优化外，它还提供了一个全云解决方案，该方案运行在下一代、弹性、裸机、AWS 基础设施上。

这将有助于快速部署安全的企业级 AWS 云资源，这些资源在操作上与基于 vSphere 的云保持一致。这将导致一个完整的交钥匙服务，该服务与本地私有云和高级 AWS 服务无缝运行。

此外，新功能使新的功能得以实现，从而彻底改变商业功能：

• VMware Cloud on AWS 灾难恢复：这是一项按需附加服务，有助于降低成本、简化灾难恢复策略并加快生产环境的上线时间。

• VMware 混合云扩展（HCX）：通过提供零停机时间迁移的批量迁移功能，有助于加速云的采用。此解决方案具有多站点感知、WAN 优化和安全性，以便尽可能快速地将迁移到 VMware Cloud on AWS。

VMware Cloud on AWS 与本地 vSphere 不同

VMware Cloud on AWS 在 Amazon 的裸金属硬件上运行 vSphere，并具有其云自动化引擎。VMware 管理员可以访问所有必要的接口，包括基于 HTML5 和 Flash 的 VMware vSphere Web 客户端，以及所有需要的 API 集成。这是一个 VMware 管理的服务，基于角色的访问控制（RBAC）将正常工作。

以下是与特定用户配置文件相关的配置：

• VMware 管理 VMware Cloud on AWS 环境，因此将权限分配给 cloudadmin@vsphere.local 以供用户访问。这可能会与需要访问 administrator@vsphere.local 环境的产品产生不兼容性。

• 用户应将工作负载放置在“工作负载”文件夹中，因为其他文件夹权限被拒绝。

• 网络配置通过 VMware Cloud on AWS 用户界面进行，因为 NSX 用户界面不可用。

• VMware Cloud on AWS 是一个托管环境，因此所有升级和维护程序都由 VMware 执行。

VMware Cloud on AWS 实施计划

VMware Cloud on AWS 的好处是它是一个可按需部署的架构化解决方案。确保成功连接现有的本地环境到 VMware Cloud on AWS 是相当困难的。

当前本地安装、软件版本和配置决定了成功连接到 AWS 实例上的 VMware Cloud 所需的步骤。本节讨论了 VMware 推荐的实施路径。

以下图显示了评估环境以连接到 VMware Cloud on AWS 环境所需的步骤。以下是基于标准流程的流程图，从身份验证开始：

VMware Cloud on AWS 的实施计划

使用以下实施计划配置本地环境以支持 VMware Cloud on AWS 连接。完成后，该环境是一个完全配置的混合云，可用于定义的使用案例。

以下是步骤的摘要：

	操作	影响	必需	VM 停机时间
1	在 AWS 上创建 VMware Cloud 账户并将其链接到客户 Amazon 账户详情	无；时间表取决于账户的创建	是	否
2	在 VMware Cloud on AWS 中创建 SDDC 数据中心	无	是	否
3	执行本地 vSphere 升级（如果需要）	vSphere 已升级，因此 VM 可能需要停机，如需升级帮助，请联系您的 VMware 销售代表获取有关 VMware vSphere 升级服务的详细信息	是（如果版本早于 6.0U3）	是（如果需要升级）
4	本地与 AWS 之间的 VPN 连接	创建 VPN 隧道所需的网络更改	是	否
5	在环境中测试混合链接模式	无	建议（如果支持混合链接模式）	否
6	用例配置	取决于正在设计的用例	否	取决于正在设计的用例
7	创建或迁移工作负载	冷迁移时的虚拟机停机时间	否	取决于是否需要冷迁移

配置 AWS 上的 VMC 的详细初始步骤

配置 AWS 上的 VMC 的详细初始步骤如下：

1. 登录到 VMware Cloud on AWS

2. 邀请用户加入云实例

3. 将凭据链接到 Amazon 账户

4. 创建 AWS 上的 VMware Cloud SDDC 数据中心

   此步骤包括在 AWS 实例上的 VMware Cloud 中创建数据中心。在此过程中，客户将被要求提供配置的详细信息，包括名称、规模、数据中心位置，最重要的是，IP 地址子网信息。在不重新部署 SDDC 的情况下，无法更改 IP 地址的详细信息，因此请确保指定正确的地址。

5. 本地 vSphere 环境升级：

   vSphere 的环境升级必须在此点进行，以确保与 VMware Cloud on the AWS 实例的功能兼容。此过程可能需要一些时间，但请验证所有功能是否兼容。环境必须达到 vSphere 6.0 更新 3 或更高版本才能得到支持，但最好使用 vSphere 6.5 以利用混合链接模式和其它功能。

安装、配置和操作程序

以下部分描述了安装、配置和操作 VMware Cloud on AWS 环境的一些基本程序。

以下是对新 VMware Cloud on AWS 环境的基本测试：

1. 登录到测试控制台：

   1. 打开一个网页浏览器

   2. 导航到vmc.vmware.com/

   3. 使用您的 VMware Cloud on AWS 凭据登录

2. 创建一个 SDDC：

   1. 点击“创建 SDDC”：

1. 1. 根据提示填写详细信息以配置您的数据中心：

1. 邀请用户：

   1. 点击“邀请用户”：

1. 1. 邀请两个或更多用户到服务

2. 调整防火墙规则：

   1. 选择已创建的 SDDC

   2. 点击“网络信息”选项卡

   3. 通过 VMC 控制台调整防火墙规则，允许从您的内部网络（或您公司的适当安全策略）访问：

1. 登录到 vCenter Server 实例：

   1. 选择已创建的 SDDC

   2. 点击“连接信息”选项卡

   3. 使用指定的凭据登录到 VMware vSphere Web Client™ (HTML5)

以下表示测试 VMware Cloud on AWS 的基本工作流程：

1. 使用 vSphere Web Client (HTML5)的 OVF 部署功能创建虚拟机：

   1. 前往工作负载资源池

   2. 部署 OVF 创建虚拟机：

1. 创建本地内容库：

   1. 如果您还没有，请在本地数据中心创建一个内容库。

   2. 将您的模板、ISO 图像和脚本添加到内容库。所有 .vmtx 模板都转换为 OVF 模板。

   3. 发布您的内容库。

   4. 在您的 VMware Cloud on AWS SDDC 中创建一个内容库，该库订阅了您从本地数据中心发布的库。内容从您的本地数据中心同步到 VMware Cloud on AWS 中的 SDDC。

2. 创建虚拟机并使用 ISO 引导操作系统：

   1. 将 ISO 上传到内容库

   2. 创建虚拟机并从内容库挂载 ISO

   3. 然后启动虚拟机

3. 在虚拟机上执行基本虚拟机操作：

   1. 迁移虚拟机

   2. 克隆虚拟机

   3. 使用 VMware vSphere vMotion® 迁移虚拟机

   4. 快照虚拟机

4. 使用 vSphere Web Client（不是远程控制台）连接到您的虚拟机

5. 使用 vSphere Web Client（HTML5）创建逻辑网络：

   1. 前往全局清单列表

   2. 前往逻辑网络

6. 将之前创建的虚拟机分配到该逻辑网络，然后开启虚拟机并编辑虚拟机设置

7. 创建一个规则，允许 sddc-cgw-network-1 上的虚拟机访问互联网：

   1. 在计算网关上创建新的防火墙规则

   2. 从您的虚拟机向互联网上的已知 IP 地址进行 ping 操作

混合链接模式测试功能

本节描述了混合链接模式测试功能。要测试混合链接模式，请执行以下步骤：

1. 使用连接信息选项卡中指定的凭据登录云 vCenter Server 实例。

2. 通过单击菜单 | 管理员进入混合链接模式配置。

3. 在混合云下，单击链接域：

1. 按屏幕上的步骤配置混合链接模式：

1. 将本地身份源（Active Directory 或 Open LDAP）添加到云 vCenter Server 实例。

2. 授予云 vCenter Server 访问本地 Active Directory 组（在先决条件中指定的组）的权限：

1. 链接到本地单点登录域（您将收到登出提示）。

2. 使用本地 Active Directory 组中的 Active Directory 用户登录云 vCenter Server 实例。本地和 VMC vCenter Server 清单都应可用。

3. 在本地和云 vCenter Server 实例中执行虚拟机操作：

   1. 创建和删除虚拟机

   2. 开启和关闭虚拟机电源

   3. 快照虚拟机

   4. 克隆虚拟机

   5. 迁移虚拟机

目前不支持在本地和云 vCenter Server 实例之间进行 vSphere vMotion。

支持和故障排除

对于您的 VMware Cloud on AWS 环境的帮助和支持，有几种选择。本节将简要介绍一些已知问题和解决方案，以帮助您解决问题。

对于您的 VMware Cloud on AWS 环境的帮助和支持，有几种选择。

1. 在您联系 VMware 寻求支持之前，请准备好您的 SDDC 支持信息：

   1. 登录 VMC 控制台，网址为vmc.vmware.com

   2. 点击 SDDC 卡片上的“查看详细信息”

   3. 点击“支持”以查看支持信息

2. 选择获取帮助或支持的方法：

   • • 聊天：点击聊天图标，然后点击“新建对话”。在聊天窗口中输入您的消息。您可以通过将图片拖入聊天窗口来包含图片。目前，聊天服务时间为周一至周五，美国太平洋标准时间上午 6 点至下午 6 点。

     • 在 My VMware 上提交支持请求：点击帮助图标，然后点击 My VMware。您将被直接带到提交支持请求的表单。

       • 查看上下文帮助：点击帮助图标。在帮助主题标题下浏览主题或在该字段中输入问题或关键词以搜索可用主题。

     • 在论坛中提问：点击帮助图标，然后点击社区论坛。您可以在这些论坛中发布问题和与其他用户讨论产品。

摘要

vRealize 工具可以自动将所有 IT 数据和事件关联到一个统一的视图中，并使用预测分析帮助客户通过在问题影响业务之前主动识别和修复问题，从而提高性能并避免中断，获得 IT 环境的完整视图。客户可以在单一解决方案中监控性能、优化其基础设施容量，并执行日志分析，同时对其应用程序和基础设施获得全面的可见性。

vRealize Operations Insight 通过帮助客户使用专为 SDDC 设计的管理工具来准备存储和网络虚拟化，为 SDDC 提供了一个入门途径。使用 vRealize Suite，虚拟化客户有一个解决方案可以完成所有工作，包括 vSphere、容器管理、合规性、日志分析、存储和网络可见性、应用程序依赖关系映射以及操作系统监控。

在下一章（第五章），我们将探讨带有 AppDefense 的基于意图的清单，我们将探索 VMware AppDefense，它使组织能够应对在本地到公共云之间保持数据安全的相关挑战。这是一个数据中心端点安全解决方案，它将威胁检测和响应直接嵌入到应用程序和数据所在虚拟化层的内核中。

进一步阅读

• 有关账户创建、链接和邀请过程的详细信息，请参阅docs.vmware.com/en/VMware-Cloud-on-AWS/services/com.vmware.vmc-aws.getting-started/GUID-9CAB2B3E-42D5-44A1-9428-E8FFD22BDD01.html上的VMware Cloud on AWS 文档。

• 对于测试，必须满足 docs.vmware.com/en/VMware-Cloud-on-AWS/services/com.vmware.vmc-aws.getting-started/GUID-BE75F0F1-2864-4926-97FE-37E635471C43.html 中列出的以下先决条件

• 如果满足先决条件，则支持混合链接模式；有关详细信息，请参阅 docs.vmware.com/en/VMware-Cloud-on-AWS/services/com.vmware.vmc-aws.getting-started/GUID-BE75F0F1-2864-4926-97FE-37E635471C43.html 中的指南

• 关于网络配置的详细信息，请参阅配置管理网关网络 docs.vmware.com/en/VMware-Cloud-on-AWS/services/com.vmware.vmc-aws.getting-started/GUID-3A7090C5-836C-4DBA-9E69-A4A1D9B6F139.html

• 请参阅 VMware Cloud on AWS 入门指南 中的 部署软件定义数据中心 部分 docs.vmware.com/en/VMware-Cloud-on-AWS/services/com.vmware.vmc-aws.getting-started/GUID-BC0EC6C5-9283-4679-91F8-87AADFB9E116.html

• 关于升级 vSphere 环境的详细信息，请参阅 vSphere 文档中心中的 VMware vSphere 升级指南，链接为 docs.vmware.com/en/VMware-vSphere/index.html

第五章：基于 AppDefense 的意图清单

本章将介绍您可以使用的方法来托管应用程序，以便您可以为最终用户提供自由度，并为管理员提供完全的控制权。您将通过使用 AppDefense 来了解业务价值，AppDefense 利用机器学*为在虚拟机中运行的应用程序创建一个基于意图的清单。它可以通过与预期状态进行比较的算法，正确地保护应用程序免受恶意行为的侵害。

在阅读完本章后，您将学会如何通过定义以应用为中心的策略来检测、保护和实施应用程序的期望状态，从而在安全运营中心（SOC）中获得相关警报。这将帮助您基于精确的决策引擎设计一个安全运营中心（SOC），而不是进行猜测。

在本章中，我们将涵盖以下主题：

• VMware 在应用程序安全方面的创新

• SOC 的应用程序中心警报

• AppDefense 和 NSX

技术要求

您可以从my.vmware.com/web/vmware/details?downloadGroup=APPDEFENSE-211&productId=742&rPId=31142下载适用于铂金版的 VMware AppDefense 插件 2.1.1。

VMware 在应用程序安全方面的创新

问题在于客户正在采用的安全策略，这些策略用于保护数据中心端点。我们特别指的是数据中心内托管应用程序的端点，而不是终端用户端点，如笔记本电脑或手机。

传统的保护应用程序的方法是监控端点以寻找已知的威胁签名。想想看防病毒软件。AV 软件有一个庞大的已知恶意软件签名数据库，它使用这个数据库在端点上识别威胁。

这种方法的问题在于，如果安全解决方案之前没有见过这种威胁，就没有签名可以匹配，因此，这种威胁会被忽略。这意味着任何全新的（或零日）威胁都将无法被检测到。

*年来，为了解决识别未知威胁的问题，基于机器学*的端点威胁检测方法变得更加突出。其理念是通过尽可能多地聚合环境中的数据，可以使用机器学*和 AI 算法来区分正常行为和威胁。这种方法的问题在于噪声。这些解决方案从环境的许多不同角落收集了如此多的数据，以至于它们难以准确检测威胁。因此，它们往往会产生大量的误报：

应用程序安全必须随着现代开发实践的速度而发展，VMware 已经开发了一种独特的解决方案来解决这个问题。与传统的安全解决方案不同，这些解决方案侧重于追逐威胁，VMware AppDefense 利用其在虚拟机管理程序中的位置来学*应用程序的预期状态，并立即对偏离该状态的情况做出响应。这种级别的应用程序可见性导致更准确的安全策略和更快的修复，简化了恶意行为的预防。这一结果成为 IT 和安全团队的一个共同事实来源，使他们能够轻松地在合规性、安全事件调查和事件响应上进行协作。

AppDefense 通过收集虚拟机的清单和来自自动化和配置工具（如 vCenter、Puppet 和 Ansible）的应用程序详细信息来构建上下文，以便理解特定机器和应用程序的意图。然后，它监控虚拟机、操作系统、进程和应用程序的行为，并将这些信息与配置期间定义的意图相关联。AppDefense 通过使用机器学*，创建一个蓝图，基于已知的好行为，说明机器和应用程序应该如何运行和通信。

一旦建立了蓝图，它就被存储在虚拟机的安全分区中。AppDefense 监控任何更改，检测并防止任何偏离预期、已建立的状态，确保应用程序、基础设施和操作系统的完整性。当检测到威胁时，它可以通过各种能力以及通过 NSX Data Center 进行执行和遏制来原生响应。

数字治理和合规性

VMware 政府解决方案使客户能够通过数据中心转型方法安全地现代化政府 IT，加强网络安全，并在基础设施、云、应用程序和端点之间简化操作。政府客户可以使用 VMware 解决方案创新 IT，以产生更大的影响，并部署以数字优先的愿景来实现使命目标。

新技术始终是客户以更好的方式提供相同服务的关键推动力。IT 现代化现在是网络安全解决方案的一个基本组成部分。IT 正在比以往任何时候都更加努力地工作，以满足对基础设施日益增长的需求，以开发成本高昂、效果不佳的系统，这些系统能够支持遗留投资和下一代应用程序。

VMware 通过扩展在计算虚拟化方面的投资到存储、网络和管理，提供了一个安全、实用和准确的方法来现代化数据中心 IT 运营的基础。现代政府数据中心是软件定义的、虚拟化的和集中的，为用户提供运行当今动态服务的可用性、可扩展性和运营效率。VMware 的 SDDC 架构利用全球一致的基础设施，实现应用程序和工作负载在本地、私有和公共云之间的无缝迁移，使客户能够以灵活性运营真正的混合云环境。这最终将在公共云和本地云之间跨越共同的基础设施和管理环境。

智能政府工作流程与自动化

IT 正在创新其交付和应用支持的方式，以跟上移动创新，并更好地响应对灵活访问政府资源和服务的内部需求。从锁定和加固的移动方法转向，客户正在利用虚拟化和云技术，将正确的应用和生产力解决方案在正确的时间交到正确的用户手中。VMware 数字工作空间解决方案通过安全、远程访问资源和数据，使政府工作人员能够更有效地服务于公民，跨越设备、地点和应用。它通过在任务计划中实现应用和 IT 服务交付的转型，提高了生产力和影响力。

作为移动工作力的基础，VMware 数字工作空间代表了应用和 IT 服务交付及消费方式的根本转变。基于软件定义的架构，数字工作空间将应用与操作系统隔离开来，实现了 Windows、云原生、Web 和移动应用的敏捷、空中交付和管理。补充微软对 Windows 10 的管理方法，VMware 数字工作空间解决方案抽象化设备和应用生命周期管理，以支持空中传输的 Windows 10 PC 和应用程序。一个企业级安全的应用程序目录，基于基于身份的访问和统一端点管理，为用户提供类似消费者的工作体验，同时不牺牲数据安全或合规性。它提供了额外的安全功能，包括对所有端点的全面可见性和管理，如 macOS 和 Windows 桌面和笔记本电脑设备，设备和数据级别的加密，细粒度的数据丢失预防（DLP）策略，以及自动合规性监控，以进一步保护数据并防止数据丢失。

转型网络和安全

客户必须通过减少总体威胁攻击面来加强网络安全。他们通过转型 IT 基础设施和治理来实现这一点。应用程序和数据正生活在越来越扩展和分布的 IT 环境中；最终用户不再被整齐地包含在边界防火墙后面，攻击者比以往任何时候都更聪明，因此网络安全努力必须不仅仅绑定核心基础设施，还要扩展到云、用户的身份和他们的设备。VMware 通过采用多层、软件定义的网络安全方法，帮助客户跟上不断变化的网络安全需求，增强了用户、应用程序和数据之间交互的可见性和控制。

网络虚拟化通过在虚拟机管理程序中嵌入网络并启用微分段，减少了物理网络环境固有的风险和低效，确保网络、安全和自动化策略遵循单个工作负载或应用程序，从而降低了基础设施的攻击面。这一抽象层还为 IT 提供了平台，以便插入额外的第三方服务以提供更高级别的安全保护，并在工作负载级别提供加密数据的理想位置。

在高度分布的计算环境、更大的跨组织防御协作和更严格的隐私法规，如通用数据保护条例（GDPR）的情况下，组织必须适应无边界计算。VMware 通过在虚拟化基础上构建并转向分层、分段和策略驱动的安全架构来帮助 IT 转型安全。VMware 解决方案与传统安全措施协同工作，以减少攻击面并防止威胁的横向移动。

VMware 方法的企业成果

VMware 帮助客户转型政府数据中心，以提高效率、扩展到云并支持共享服务。VMware 的方法是利用虚拟化和超融合基础设施（HCI）来构建一个敏捷、以服务为导向的数据中心，通过以下方法实现标准化、集中化和混合云就绪：

• 减少数据中心占地面积、硬件和运营成本，以优化数据中心

• 仅使用所需资源构建一流的私有云，并双向扩展到公共云

• 在多个组织中整合 IT 系统、功能和服务的共享服务模型

• 支持云原生应用程序开发和平台，以及传统应用程序

• 通过更快、按需交付 IT 资源来提高效率、敏捷性和 IT 服务水平

• 将节省的资金重新投资于应用程序开发和敏捷性

以下是为不同用例提供的 VMware 解决方案方法：

• 通过一个全面和现代的安全平台减少总威胁攻击面：

  • VMware 方法：通过在应用程序基础设施和终端点上应用一个无处不在的软件层，实现一个软件定义的安全和治理框架，这些终端点独立于底层物理基础设施：

    • 将安全功能从底层物理基础设施中解耦，并将保护措施更靠*整个 IT 环境中的数据/工作负载

    • 在数据中心和云基础设施中嵌入内在安全

    • 降低风险并改善安全态势

    • 降低操作复杂性

• 通过物联网提供服务和保护：

  • VMware 方法：VMware 提供企业级物联网设备管理和监控解决方案，解决机构在将物联网用例从边缘到云端的上线、管理、监控和安全方面面临的挑战。只需一个控制台即可配置、安全、管理和监控物联网基础设施。VMware 方法的好处如下：

    • 简化复杂性

    • 提高可靠性

    • 转变安全

    • 加速创新并加快投资回报率

• 构建新的能力、运营模式和包括以下内容的服务：

  • 智慧建筑

  • 国防：改善资产跟踪和供应链管理；网络中心战，通过摄像头、红外传感器、探测器、无人机和卫星提供战场共享感知

  • 车队遥测：使用传感器远程监控车队内车辆的位置、性能和行为

  • 监测天气和大气条件

  • 提升安全和公共卫生

  • 智慧城市

• 开发电子政府和安全框架以实现数字公民：

  • VMware 方法：VMware 通过自动化 IT 基础设施的每一层，帮助政府通过从数据中心到终端用户设备的数字化来现代化 IT。这种抽象使得在整个生命周期中，可以通过编程方式全面可见和控制系统组件，增强安全性、提高效率并支持现在和未来的现代框架：

    • 提高公共服务交付的成本和质量

    • 提供新的功能

    • 加快创新

    • 维护公民信任、数据安全和隐私

• 采用零信任安全模型：

  • VMware 方法：使软件定义网络能够分割和隔离网络，并控制数据中心内的横向移动。它将网络嵌入到虚拟机管理程序层，将网络、自动化和安全服务附加到由策略驱动的、与工作负载或应用程序同步的工作流程中，从而实现一种分层、深度防御的安全方法：

    • 将网络保护扩展到应用程序和数据

    • 确保安全策略与应用程序同步

    • 通过自动化和编排跨单个工作负载系统地执行策略

    • 在网络中行使最小权限和单元级信任的能力

    • 包含攻击的横向传播

    • 减少错误和低效

使用 AppDefense 进行全球扩展

AppDefense 基于机器学*技术进行威胁检测和响应解决方案。客户信任数字信息，但任何数据泄露都会影响他们的消费者信心，以及他们的声誉。数据对于组织在当今市场保持竞争力至关重要，因此数据安全不能被妥协。

AppDefense 帮助组织解决与保护其数据安全相关的一些挑战。它是一个数据中心端点安全解决方案，将内置的威胁检测和响应解决方案嵌入到 vSphere 内核中，包括主机应用程序和相关数据。它整合了每个端点上的所有所需服务的正确状态的信息。它还可以在发生时检测到未经授权的更改。

以下是一个 AppDefense 仪表板截图，其中包含三个未清除的警报：

VMware AppDefense 专注于通过消除对整个环境进行钻探的需要，追逐可能构成威胁的已知或未知错误行为，来验证端点的已知正确参数。通过最小化误报的发生，安全团队能够以充分的信心将异常检测为真正的威胁。AppDefense 位于攻击面之外，因此它本身不会被破坏。

针对安全运营中心的应用程序中心警报

AppDefense 会发出一个智能警报，这对环境来说非常重要。只有带有自动响应的受信任警报才能让安全团队能够专注于从他们的环境中寻找和摧毁威胁，而不是从错误的数据中寻找威胁。安全运营中心（SOC）可以使用这个工具来有信心地检测威胁，并自动响应威胁。首席信息安全官（CISO）组织分为安全架构师和安全运营。安全架构师负责制定用于保护特定应用程序的政策，而安全运营负责实际监控和识别环境中的威胁。

安全架构师审查新应用程序并确定它们应该如何受到保护。今天，他们对应用程序的组成、应该（或不应该）运行哪些进程以及它们应该如何通信（以及与谁通信）了解非常有限，他们甚至不知道该去找谁解答他们的问题。审查过程可能需要数月，而且，他们使用的政策通常是通用的，重点是确保应用程序已打补丁并且日志被监控。

使用 AppDefense，架构师从一开始就能获得应用程序预期状态和行为的可信清单，这使他们能够定义特定于应用程序的政策，从而在应用程序最终部署时为 SOC 去除猜测工作。这使得审查过程更加有效、更少手动操作，并且速度更快，这对于组织转向更敏捷的应用程序开发方法尤为重要。

一旦应用程序部署，检测应用程序是否受到损害的任务就落在了 SOC 上。今天，他们面临着大量的误报和噪音，需要从中找出合理的解释。如果他们发现问题，补救措施是手动且劳动密集型的。使用 AppDefense，当收到有关出现问题的警报时，SOC 可以相信该警报是合法的。此外，他们可以自动化补救措施，以便快速有效地消除威胁，最大限度地减少对环境的损害。

转变应用程序安全准备

在 DevOps 环境中，应用程序的开发、更改和销毁都非常迅速。带有增强功能的应用程序代码经常更改，这使得安全团队很难定期更新/了解应用程序中的新修订。客户不能冒险让关键数据受到损害，这可能会损害他们的宝贵声誉。客户必须确保所有平台上的安全服务紧密保护他们的网络、应用程序和数据中心端点位置。

几乎任何拥有计算机的人都可以对特定组织发起攻击，并且每天都有新的威胁类型被开发出来。我们无法持续关注威胁以破坏与 IT 安全相关的所有挑战。

CISOs 负责保护动态和分布式 IT 环境中驻留的应用程序和数据。客户必须选择新的云原生应用程序开发流程，并且还必须实施加强其商业目标的安全措施。

AppDefense 通过确保“良好”而不是“追逐不良”的方式来保护应用程序。AppDefense 通过其目标理解应用程序行为，并对照应用程序期望状态进行检查。当应用程序被操纵时，AppDefense 会自动响应。这是一个简单而强大的工具，通过提供更多上下文和控制来缩小攻击面。

AppDefense 也可以在容器环境中工作，并帮助客户在任何平台、跨区域边界上保护他们的应用程序。AppDefense 为数据中心应用程序提供基础层保护。AppDefense 是唯一一个可以跨所有平台，以一致的方法发现上下文、定义带有警报的规则和补救措施的解决方案。客户可以通过集成容器支持，在所有应用程序中启动最小权限执行。

与开发者、安全和运维团队一起创新 IT 安全

安全团队可以使用 AppDefense 为经常进行应用程序开发和部署的客户建立安全审查流程。

由于终端用户需求不断变化，应用程序和基础设施今天扩展得更快。这将挑战安全团队在应用程序定期被重写和重新部署时，放弃传统的、手动的方式去调查和管理变更。安全团队应该了解应用程序的意图，并为其期望状态定义安全策略。

我们通过将其集成到 CI/CD 管道中，使用配置工具和自动化框架来使用 AppDefense。我们可以通过维护一个与按需应用程序团队保持同步的预期状态的可信映射，通过实时监控来定义期望状态，以支持 DevSecOps 方法。

容器化应用程序的最小权限安全

AppDefense 提供了一个 API，使容器安全合作伙伴能够集成到平台中。AppDefense 可以从容器编排系统中获取工作负载上下文，并且还可以配置由容器安全供应商执行的政策。

Aqua Security 是可以与 AppDefense 容器生态系统集成的第三方工具之一；它通过调查和执行行为，为容器执行时提供运行时保证。AppDefense 与 Aqua Security 将帮助容器运行时配置文件，以便 VMware 可以在整个数据中心管理/维护安全范围，并且 Aqua 还会将引人注目的警报传输到 AppDefense 控制台，用于管理和解决。通过集成到可以扩展到混合云模型的容器安全解决方案中，容器自带自动化引擎和定义了期望状态的技术。

AppDefense 支持运行在所有平台上的 VMware vCenter 库存，如虚拟服务器、裸金属服务器和任何云环境中的容器工作负载。AppDefense 通过欧洲基于数据中心的支持，支持欧洲客户的数据本地化政策。

通用数据保护条例（GDPR）（法规[EU] 2016/679）是一项建立和合并欧盟内个人数据隐私权的法规。GDPR 还关注个人数据超出欧盟区域边界的出口。GDPR 的第一个目标是控制个人数据，如个人的姓名、地址和国民身份证号码，这是一项基本权利，并通过协调所有欧盟国家的数据保护规定，使全球商业的监管环境易于理解。

欧洲联盟的通用数据保护条例（GDPR）扩大了当前欧盟数据保护法律的适用范围，涵盖了处理个人欧盟数据的非欧盟组织。数据保护批准的协调应使非欧盟组织更容易遵守严格的数据保护合规当局，并对不遵守规定实施最高惩罚。VMware 将与欧盟的 GDPR 保持一致。

VMware 可以通过在其标准合同条款内构建合规框架来应对从欧盟出口个人数据的问题。我们可以在当前欧盟法律下，根据需要为客户提供高水平的保护。VMware 的标准合同条款包括全球范围内 VMware 及其子公司之间个人数据流动的内部共识。VMware 的客户依赖于 VMware 在安全港计划下的认证，以及 VMware 处理客户个人数据的方式。VMware 的内部标准合同条款可由其任何客户使用。

VMware 帮助客户在数据安全方面与 GDPR 保持一致，以便客户可以与隐私专家交流想法，并通过支持预期法律来执行业务流程。

AppDefense 是一款具有许多优点的基于云的安全工具，但为了性能和数据本地化，拥有本地数据中心非常重要。欧洲客户必须遵守有关数据本地化的监管合规。AppDefense 服务将仅从位于欧洲的本地数据中心向欧洲客户提供服务。AppDefense 已推出一项关键的云安全服务，以最大化全球拥有区域数据中心的客户。

印度政府也有这样的政策，他们只能从在印度设有数据中心的公司获取云服务。

AppDefense 收集和利用终端用户和业务数据，从合规的角度来看。它还适用于不同的全球数据法律/法规。AppDefense 收集客户电子邮件地址进行身份验证，然后将其放入服务中进行检查，以查找个人信息。AppDefense 还从客户受保护的应用程序中获取主机名、IP 地址和进程信息。所有这些关键数据从合规角度来看都至关重要。AppDefense 支持托管在不同类型云中的应用程序。

带有 AppDefense 的增强安全性

客户正在更新其数据中心的基础设施，并且正在努力解决所有严重的安全漏洞，而无需额外花费任何费用。AppDefense 与 VMware NSX 结合，将通过微分段增强网络安全，并保护服务器免受未知威胁。

大多数安全漏洞无法通过单一产品（只能处理单个问题，而没有完整的解决方案）或工具来解决，因为这些产品更基础、更具架构性。AppDefense 通过在 vSphere 内核中植入 AppDefense，使安全成为网络和应用架构中业务运行的一个固有部分。安全是数据中心端点的原生部分，由应用程序组成。AppDefense 帮助其客户应对安全模型中安全事件点日益频繁和成本上升的问题，这些模型主要关注未识别的威胁。AppDefense 传达了一种基于目的的安全模型，该模型确定应用程序应该做什么——已知的正确。将其与黑客将要做的事情——已知的错误进行比较。

AppDefense 和 NSX

AppDefense 为在 vSphere 环境和各种云环境中运行的应用程序提供保护。NSX 和 AppDefense 相互补充，但 NSX 不是 AppDefense 服务的强制性要求。如果 AppDefense 与 NSX 集成，可以利用自动隔离受损害的数据中心端点等自动化响应技术。AppDefense 在一种新的安全模型中表现出色，该模型具有原生、基于目的和应用中心的方法。AppDefense 将为计算执行与 NSX 为网络执行相同的任务，通过为业务应用程序创建最小权限环境。我们可以监控运行中的应用程序与其期望状态，并可以通过自动响应尝试利用应用程序的攻击来调查它们。

AppDefense 具有独特性，因为它位于虚拟机管理程序内核中，以便更好地解释数据中心端点的期望状态和行为。它实时监控端点，以检测从已知正确状态的不批准更改。当检测到应用程序的威胁时，AppDefense 使用 vSphere 与 NSX 进行自动化响应。

AppDefense 补充了多种安全解决方案，但它与两种主要的端点安全解决方案竞争，如下所示：

• 基于签名的传统产品（防病毒软件、反恶意软件、入侵防御系统等）

• 新一代端点安全（端点检测与响应（EDR）、机器学*、行为分析等）

与之前解决方案相比，AppDefense 通过识别应用程序期望状态与可能警告之间的偏差而不断发展，同时它也具备自动化响应能力，这些能力可以与其他安全工具在多个方面进行集成。

VMware 从数据中心到终端用户，协助客户使用安全和数据保护功能。通过识别潜在的数据保护漏洞，确保客户环境端到端的安全：

• 数据访问和数据传输（使用 VMware NSX）：创建安全策略以防止数据在未经批准的网络中移动

• 数据访问（使用 Horizon 和 Workspace ONE）：创建策略引擎以实施基于角色的数据访问，并进行身份检查和验证

• 数据存储（使用 VMware vSphere 和 vSAN）：启用数据加密

• 数据删除（使用 VMware vSphere 和 AirWatch）：擦除数据，包括单个数据

AppDefense 与微软的基于虚拟化的安全工具（VBS），如 Device Guard、Credential Guard 和 AppLocker 不同，因为这些工具仅针对 Windows 构建，且不支持 Linux 工作负载。此外，这些解决方案都没有设计用于检测和响应数据中心端点的威胁。VBS 使用虚拟机管理程序来帮助保护内核和其他操作系统部分。AppDefense 专注于应用程序。保护应用程序意味着保护应用程序组件的完整性和行为，而不仅仅是操作系统。即使 VBS 不存在或未启用，AppDefense 也提供操作系统保护。AppDefense 还向安全运营中心（SOC）提供检测和响应任何妥协的能力。Device Guard 专注于白名单，指定哪些可执行文件可以在机器上运行。它不执行行为白名单。它不采取以应用程序为中心的视角来创建、更新和监控这些策略。它不支持自动化响应集成。所有这些都是提供高效用于 SOC 的解决方案的必要组成部分。AppLocker 是较老的应用程序白名单解决方案，专注于终端用户端点，并遭受了传统白名单所具有的所有问题。关于何时使用 AppLocker 而不是 Device Guard，存在很大的混淆。

AppDefense 为应用程序执行白名单和行为分析。传统的白名单基于监控和验证允许安装在机器上的内容。然而，这种方法忽略了行为组件。机器允许做什么？AppDefense 将其方法中的这两个组件结合起来，以确定应用程序的预期状态。AppDefense 还从整体上看待应用程序的行为，而不仅仅是关注单个数据中心端点。AppDefense 在云中存储虚拟机清单、机器名称、预期的进程行为、预期的网络流和安全警报。AppDefense 保存有关客户数据中心环境和安全状态元数据。AppDefense 不会在云中存储任何应用程序数据，也不处理来自客户的实际应用程序数据。存储的唯一数据是维护基础设施安全态势所需的数据。

我们保护存储在云中的信息，因为我们非常重视 AppDefense 服务的安全性。该服务由 VMware SOC 管理并保护，该团队同样负责管理 VMware 所有云服务的安全以及 VMware 的本地数据中心。AWS 中的任何配置更改或行为都由 SOC 密切监控，并需要经过授权的变更控制流程。所有数据都通过加密隧道发送到 AppDefense 服务，并且存储的所有数据都进行了加密。

AppDefense 使用第三方服务提供商，并利用精选的少数第三方 SaaS 服务。所有第三方供应商都经过内部安全和法律团队审查，并与 VMware 签订了数据隐私协议。

AppDefense 作为 SaaS 服务进行管理，客户通过使用 AppDefense 获得以下好处：

• 安全团队不需要部署、管理和维护软件，这不是他们的核心专长。

• 客户可以受益于 vSphere 安装基础的集体知识。这意味着我们可以从不同租户的大量机器上运行的行为建立基线，以便更快地识别异常和安全威胁。

• 云交付模型使我们能够定期更新和更改一些异常检测逻辑，而无需要求客户安装和管理软件更新。

• 将服务作为云服务提供，允许客户从单一位置管理其环境的安全态势。

AppDefense 理解应用程序的预期状态，应用程序的预期状态包括构成应用程序的 VM、服务和二进制文件等信息，以及与核心应用程序共存的其它软件，如安全和管理系统软件。它还包括行为信息，如各种进程之间的网络交互。AppDefense 还与 vRealize Automation、Puppet 等配置系统集成，以获取预期状态的信息。然后，它通过运行时发现行为来增强这些信息，以创建全面和验证的预期状态。如果 VM 使用 vMotion 在主机或集群之间移动，AppDefense 策略也会随之移动，类似于 NSX。AppDefense 的管理域边界是 vCenter，因此目前不支持在 vCenters 之间移动 VM。

可能会创建误报的预期应用程序更改有两种形式：软件更新和学*期间未表现出的行为。为了限制误报，请执行以下操作：

• 我们建议为应用程序设置一个延长和可变的学*期

• 我们支持通配符，并执行智能和自动通配符匹配

AppDefense 不会在端点或主机上消耗大量系统资源，因为它出奇地轻量级，在主机上消耗的资源最少。AppDefense 使用简单的方法来理解应用程序的预期状态并监控变化，而不是依赖于复杂的算法和计算，这是其他下一代端点安全解决方案通常的工作方式。AppDefense 与安全信息和事件管理（SIEM）和其他下一代安全解决方案集成，因为它是一个开放平台，允许 SIEM 和其他安全系统消费其警报和应用程序上下文信息，以及利用其自动响应功能。

AppDefense 通过集成 DevOps 自动化工具以获取可信的预期状态数据，与配置管理工具、编排引擎和云管理门户集成。您还可以与 vRealize Automation 集成，并添加对 Puppet 等工具的支持，以实现自动化配置和编排。

详细的实施和配置计划

以下部分涵盖了 AppDefense 成功部署所需的组件和步骤。将被 AppDefense 保护的目标应用程序环境需要具备以下条件：

• 至少两个运行 ESXi 6.5a 或更高版本的 ESXi 主机

• 管理 ESXi 主机的 vCenter 6.5+

• VM 硬件版本 13

• AppDefense 设备 OVA 的 IP 地址以及到互联网的 HTTPS 连接

• 至少一个在 Windows Server 2012 或 2016 64 位上运行的类似生产的应用程序

• 优先选择的应用程序应该是分布式的（例如，Web-App-DB）

• NSXv 6.3 或更高版本

• vRA 7.2 或更高版本

AppDefense 部署的环境准备

AppDefense 部署的环境准备如下：

• 第一阶段：

  • 安装 vCenter

  • 安装 ESXi 主机

  • 安装 NSX Manager

  • 安装 vRealize Automation

安装和部署 AppDefense 组件：应用程序和基础设施团队负责安装和支持 AppDefense 平台组件，并选择目标应用程序。应用程序团队还负责为目标应用程序提供测试，并模拟对已部署应用程序的标准更改。

• 第二阶段：

  • 提供 AppDefense 登录

  • 下载 AppDefense 设备

  • 部署 AppDefense 设备 OVA

如果满足以下条件，AppDefense 部署将成功：

• • AppDefense 在环境中成功部署（所有组件）

  • AppDefense 已成功连接到所有外部组件（vCenter、NSX 和 vRA）

  • 从 vCenter 可见的虚拟机库存可以从 AppDefense 管理控制台访问

  • 描述的关键工作流程应成功完成

它从捕获虚拟机的预期目的、状态和行为开始。在这里，我们利用 vSphere 的独特属性，即应用程序可见性。虚拟机管理程序允许您看到运行时状态（VM 中正在运行的内容）和配置状态（最初在那里配置的内容）。

• 第三阶段：

  • 部署一个 AppDefense Manager 实例

  • 复制 UUID 和 API-KEY

  • 修改application.properties文件

  • 验证 AppDefense 设备连接性

  • 验证 NSX Manager 连接性

  • 验证 vRealize Orchestrator 连接性

通过配置 AppDefense 组件完成 AppDefense 部署：这些解决方案的所有技术要求（IP 地址、DNS、虚拟机、NTP 等）都需要满足。客户必须通过审查其环境中的允许行为准则、配置保护策略、监控受保护的应用程序以及使用 VMware 提供的工具、内部工具或手动触发违规来帮助实施团队。将带有 AppDefense 的测试应用程序运行和保护将根据当前和即将到来的安全威胁定期评估。

• 第四阶段：

  • 在 ESXi 主机上安装主机模块

  • 在应用程序服务器上部署客户机模块

  • 启用客户机完整性

  • 验证应用程序服务器显示为就绪状态

创建具有基础检测和响应功能的应用程序范围：AppDefense 的核心是定义应用程序的预期状态。预期状态包括应用程序的组成、进程级、入站和出站连接行为，以及它们在更广泛的应用程序上下文中的关系，因为这些应用程序根据客户需求用于连接或集成。在部署期间将使用这些方法之一来创建预期状态。

• 第 5 阶段:

  • 在 AppDefense 中为应用程序创建一个范围

  • 在 AppDefense 中为应用程序创建服务

  • 验证捕获过程已运行几周

创建应用程序范围：您可以使用来自 vRealize Automation 的基础设施蓝图来创建 AppDefense 中的服务和应用程序范围/组合，您还可以在 AppDefense 中手动定义应用程序组合。

• 第 6 阶段:

  • 创建多机蓝图

  • 在蓝图上使用范围和服务标记虚拟机

  • 验证 AppDefense 中的范围创建

验证和保护模式：我们可以在应用程序上运行 AppDefense 发现模式几周，以自动学*应用程序行为。您还可以修改和验证应用程序的预期状态（允许的行为）。

• 第 7 阶段:

  • 验证行为

  • 根据需要添加/修改/删除行为

  • 将操作更改为验证和保护

  • 观察警报日志中的默认规则违规

修复测试：测试自动和手动工作流程以执行以下修复操作：

• • 挂起

  • 关闭电源

  • 快照

  • 阻止和警报

  • 检测测试和事件调查

  • 通过触发未授权行为进行预期状态偏差测试

  • 事件调查

  • 带有详细通知的警报

  • 配置事件

• 第 8 阶段:

  • 修改关闭电源的规则

  • 触发未授权行为

  • 验证日志中的关闭电源和相关的警报

  • 修改挂起的规则

  • 触发未授权行为

  • 验证日志中的挂起和相关的警报

  • 修改阻止和警报的规则

  • 触发未授权行为

  • 验证日志中的区块和警报以及相关的警报

  • 修改快照规则

  • 触发未授权行为

  • 验证日志中的快照和相关的警报

使用 NSX Manager 进行修复测试:

• • 创建和更新预期状态的简便性

  • 事件响应自动化的简便性

  • 当使用预期状态的偏差作为安全或合规事件信号时，低噪声与信号比

  • 隔离

  • 保护策略的配置

• 第 9 阶段:

  • 修改隔离的规则

  • 触发未授权行为

  • 验证 NSX AppDefense 安全标签已应用

  • 验证 NSX AppDefense 安全组包含

  • 验证 NSX AppDefense 安全策略已应用

  • 验证虚拟机无法再进行通信

摘要

数字化转型有潜力彻底改变政府与公民/选民的联系方式、保护敏感信息以及实现组织使命的方式。然而，改革政府的业务是一个复杂的任务。主要障碍包括孤立的遗留系统、应用程序和流程；资金和人才短缺；复杂的采购流程以及文化冲突。尽管存在这些普遍的挑战，政府领导人认识到，数字化转型是服务数字时代公众的必要手段。VMware AppDefense 有助于加强基础设施和端点之间的数据安全，通过降低网络安全风险来保护敏感公民数据和隐私。

在下一章，第六章，基于机器学*的智能日志管理中，你将了解 vRealize 工具如何自动将所有 IT 数据和事件关联到一个统一的视图，并呈现 IT 环境的完整图景，你还将使用分析来预测并为客户提供服务。我们还将通过使他们能够主动识别和修复问题，在这些问题影响业务之前提高性能并避免中断。

第二部分：使用 VMware 解决方案的机器学*用例

VMware 必须以完全自动化的方式处理事务，并需要能够做出决策的机器。他们目前正在尝试至少自动启动第一项补救措施，并且只有在机器没有响应或以预期的方式行为时，才会寻求帮助。这就是今天趋势所在，因为人们正在用机器学*技术进行创新。VMware 正在为基于机器学*的响应基础设施和应用做好准备，以便能够针对它们采取行动，并且不应依赖于任何子系统，通过精确地说明实时场景中对系统的影响。在接下来的几章中，我们将了解管理工具集，重点是机器学*技术。

本节包含以下章节：

• 第六章，基于机器学*的智能日志管理

• 第七章，云中的机器学*作为服务

• 第八章，基于 Skyline 的机器学*规则引擎

• 第九章，使用 vRealize Code Stream 的 DevOps

• 第十章，使用机器学*转型 VMware IT 运营

第六章：基于机器学*的智能日志管理

在本章中，我们将探讨 vRealize Log Insight 的架构及其工作原理。我们还将讨论智能数据摘要的发生及其将相似消息聚类的功能。vRealize Log Insight 还具有自动模式提取功能。它具有通过索引和智能分组在物理、虚拟和云环境中进行快速故障排除的能力，这有助于通过精确的根本原因分析快速找到解决方案。

我们将学*如何通过将 vRealize Log Insight 与第三方工具集成，利用 vRealize Log Insight 进行自动修复，以及索引和消息分组背后的逻辑。

本章我们将涵盖以下主题：

• 使用 vRealize Log Insight 的智能日志管理

• 云运维阶段

• VMware vRealize Network Insight（vRNI）

技术要求

您可以下载以下内容：

• VMware vRealize Log Insight 4.6.2，请访问my.vmware.com/web/vmware/details?downloadGroup=VRLI-462&productId=676&rPId=28154

• VMware vRealize Operations Manager 6.7.0，请访问my.vmware.com/web/vmware/details?downloadGroup=VROPS-670&productId=676&rPId=28154

• VMware vRealize Network Insight 4.0.0，请访问my.vmware.com/web/vmware/details?downloadGroup=VRNI-400&productId=832&rPId=29784

• 日志智能，请访问cloud.vmware.com/log-intelligence

使用 vRealize Log Insight 的智能日志管理

对于 VMware 客户来说，了解全面的云管理平台产品至关重要，这也是自动化和简化数据中心运营努力的一部分。

我们可以使用 vRealize Log Insight 作为单一解决方案来规划日志管理解决方案。我们应该了解更大、更具战略性的 SDDC 管理故事。日志管理是一个点解决方案，它融入更大的图景并提升讨论。Log Insight 可以通过大量可用的内容包进行扩展。与其他解决方案不同，随着数据量的增长，它不会额外收费。

日志智能价值主张

VMware vRealize Operations 和 vRealize Log Insight 帮助云服务提供商在物理、虚拟和云基础设施上提供服务。两者可以一起在简单、易于使用的统一控制台中关联来自应用程序到存储的结构的和非结构化数据。这是通过提供对性能、容量和配置的控制来实现的，有助于进行基于策略配置的主动行动。vRealize Log Insight 通过基于智能分组和具有创新搜索能力的实时日志管理为 vRealize Operations 增加价值，以快速解决和增强操作分析。

以下表格显示了 VMware Cloud on AWS 功能的日志智能（LInt）核心：

VMC on AWS + LInt 功能	LInt 对 VMC 的核心	LInt 30 天免费试用	LInt 付费（每月每 GB 价格）
审计日志收集	无限制	无限制	无限制
非审计日志收集	1 GB/天	无限制	按需/客户选择级别
日志保留	7 天	30 天	30 天
审计日志内容	可用	可用	可用
可视化（仪表板）	可用	可用	可用
搜索并保存查询	可用	可用	可用
长期归档		可用	可用
警报		可用	可用
通知		可用	可用
事件转发		可用	可用
非审计日志内容		可用	可用
外部 Web 钩子		可用	可用

使用Wavefront和日志智能进行端到端 DevOps 故障排除，能够根据上下文（时间、来源和自定义标签）进行跨启动，并从日志中提取指标。

以下图表显示了 Wavefront 和日志智能之间的数据流动流程：

开发团队在经过广泛的过滤后从日志分析工具中获得精确数据，并将这些数据推送到Wavefront仪表板以获得所需输出，这将帮助他们提升应用能力。这是一个持续循环，三者紧密集成以实现最终共同目标。

日志智能指标具有以下功能：

• 提供关键错误数量以及与之相关的警告数量

• 使用 Wavefront 作为集中式警报仪表板

• 将日志中引发的警报转发到 Wavefront

• 与日志关联相关的警报跨启动

• 应用感知关联和跨启动

• 指标和日志内容

Wavefront 是一个专为处理现代云应用速度和动态性高规模而设计的云原生指标监控和分析平台。运行真正的云原生应用（如 Box 等）的 DevOps 和开发团队使用 Wavefront 来监控他们的云服务。Wavefront 具有达到 前所未有的规模 的能力。Wavefront 平台从分布式应用、容器、微服务、混合公共云基础设施，甚至商业数据中收集指标。一旦指标数据进入 Wavefront 时间序列数据库，我们就可以通过 Wavefront 查询语言的形式应用强大且灵活的分析。

工程师使用 Wavefront 以前所未有的规模了解其云服务和分布式应用的性能。我们能够即时了解所有云服务。我们可以更快地排除故障，并使用 Wavefront 主动警报和检测异常的领先指标。我们能够即时访问并统一可见性，这推动了代码发布的敏捷性，使一切都能保持相同的可见性。一旦 Wavefront 进入一个组织，其采用就会在数百名工程师中传播，从而实现自助服务方法。

Wavefront 实现简单，易于通过其分析引擎 Wavefront 查询语言进行扩展，该语言在 Wavefront 查询语言中包含超过 100 个分析函数。它很容易通过分析驱动的可见性自定义仪表板，覆盖云应用和基础设施。Wavefront 的定价是根据 vRealize Operations Manager 的摄入率和每台主机来定义的。客户可以清楚地看到指标速率消耗，根据需要调整，并且无需任何隐藏成本即可用于预算。Wavefront 数据源是通过集成开源代理、API、代码库和事件、日志中的指标以及其他工具（DevOps 等）进行原生指标摄入的。它可以轻松扩展到每秒 4,000,000 个 数据包（pps）。它已在数千名开发/DevOps 团队中的工程师中得到企业级采用。Wavefront 已经证明了其 SaaS 提供方案，并且已成功集成到 Box、Lyft、Intuit、Workday 等流行的 SaaS 应用程序中，覆盖了数千名开发者。

Wavefront 支持容器技术，如 Docker、Pivotal Container Service（PKS）、Kubernetes 和 Elastic Container Service（ECS），无需额外配置。容器指标可以无问题地添加和扩展，而不会出现任何性能下降。它是从头开始构建以进行扩展的。绿色客户也可以利用 Wavefront 的 LInt/Insight，而非绿色客户可以选择将日志转换为其他日志工具的指标。

Wavefront 不是一个访问策略管理器（APM）工具，但它像任何其他 APM 工具一样摄取 APM 指标。它还支持与其他任何长期趋势数据源的相关性。它还支持使用开源库进行代码检测，提供应用程序可见性（StatsD、Micrometer 和 DropWizard），并且对于大规模的微服务和动态自定义应用程序来说非常理想。Wavefront 可以补充现有的 APM 工具。它支持使用 Holt-Winters 和自回归积分移动平均（ARIMA）预测算法进行预测预测。它还可以与超过 125 个应用程序集成，并支持 Azure、GCP 和 AWS。

日志智能对服务提供商的关键优势

LInt 对服务提供商的关键优势如下：

• 积极识别和修复新兴的性能、能力和配置问题，实现最高级别的可用性。

• 持续监控和自动能力管理优化稀缺的基础设施资源。

• 在单个控制台中，对多个租户、应用程序、计算、存储和网络具有全面的可见性。

• 它具有自动执行 IT 政策、配置标准和法规要求的功能。

• 根据环境的操作特性进行工作负载平衡，以实现工作负载的最佳放置。

• 自定义数据中心（CDCs）允许服务提供商将来自一个或多个 vCenter 环境的宿主、集群和数据中心组合起来，并将这些 CDCs 映射到单个租户，以创建目标逻辑分组，提供全面的能力管理、规划和所有分析徽章的支持。

• 它通过缩短故障排除时间、提高平均修复时间（MTTR）和减少人工努力，降低了运营支出并提高了运营效率。

VMware Cloud on AWS 的日志智能提供了对 VMware Cloud on AWS、AWS 和本地 SDDC 的基础设施和应用程序日志的统一可见性。VMware Cloud on AWS 通过日志智能支持其原生审计日志，以实现更快的监控结果和故障排除，作为基于自定义触发器/仪表板的实时异常警报的核心服务，以可视化趋势和有效的自定义警报通知。它将在日志中提供高性能的搜索功能，以支持从单一控制台对广泛的应用程序进行根本原因分析。

审计日志示例

VMC 客户可以使用探索日志的日志智能功能在日志智能选项卡中查看审计日志示例。以下为 VMC 和日志智能选项卡的示例视图，以及 VMC 审计日志信息的示例：

• 虚拟机创建；虚拟机删除；虚拟机修改；防火墙规则创建

• 防火墙规则删除；防火墙规则修改；NAT 规则创建；NAT 规则删除

• 创建 IPSec VPN；删除 IPSec VPN；修改 IPSec VPN；登录失败次数

• 虚拟机启动失败；创建逻辑网络；删除逻辑网络

以下截图显示了日志智能仪表板：

vRealize Operations 和 vRealize Log Insight 可用于管理服务提供商、私有或公共云上的工作负载，包括 vCloud Air。VMware VRealize Business（vRB）运营和 vRealize Log Insight 作为 vApps 提供，并将在任何安装/认证的 vSphere 硬件基础设施上运行。

VMware 集成 OpenStack（VIO）是包含适配器以集成 VMware 计算、网络和存储虚拟化解决方案的 OpenStack 版本。VIO 有多个用例，不仅包括基本的开发者对基础设施资源的访问。vRealize Operations 和 vRealize Log Insight 可以与 OpenStack 一起使用，以在部署开放 API 集时使用 OpenStack。VIO 用于依赖开放 API 的 Web 规模应用程序，需要一个管理解决方案来确保 SLA 和持续的基础设施管理。我们将在下一节中介绍云运营阶段，这将解释我们如何通过最佳服务来简化云运营流程以节省更多 OpEx。

云运营阶段

随着客户向云迁移，VMware 提供了一套最佳实践来组织、运营和衡量成功。目标是让客户能够访问最佳实践，以便他们能够充分利用这一转型。

财务透明度、流程成熟度、组织设置和技术实施是旅程每个阶段成功的关键因素。

VMware 为进入 VMware 云计算之旅定义了以下阶段：

• 标准化

• 服务代理

• 战略合作伙伴

以下各节将描述这些阶段。

标准化

我们可以将这一阶段与服务器整合相结合，并强调一个服务目录，最终用户可以从任何地方、任何时间、任何设备按需访问云解决方案。这将有助于快速部署各种用户和应用程序的服务，无论其领域如何。服务目录通过帮助业务用户在云环境中更高效、更有生产力地完成日常任务，协助业务用户。

在这个阶段，我们需要以下功能：

• TCO/ROI：对其运营成本和资产价值的清晰可见性及其能力

• 业务和 IT 用户：云计算的专业技能

• 应将 IT 流程与所有合规性自动化

• 持续创新与持续改进

• 基于自助按需配置门户的应用程序配置

• 无缝适配基于 SaaS 的应用程序

• 基于预测分析的智能运营

服务代理

我们必须首先设计一个通用的平台，用于服务驱动的云部署。IT 将作为服务代理，在云环境中提供业务服务。IT 可以通过增加外部容量来内部和外部托管云环境，或为业务用户提供基于供应商的 SaaS 应用程序的访问。这样，IT 可以最小化开发和配置时间，并通过提高服务质量和服务敏捷性更好地协助业务目标。

在这个阶段，我们需要以下能力：

• 定义应用程序生命周期并设计支持持续开发流程的应用程序

• 以按使用付费的模式提供服务

• 通过将所有工具集成到单个界面中来自动化大部分操作任务

• 通过展示/计费工具对 IT 基础设施/应用程序的使用进行计量

• 将资本支出和运营支出分开

• 将基于项目的做法转变为基于需求的以实现成本优化

• 将所有 IT 运营流程集成以获得单一、统一的控制台

• 设计按需服务和开发流程

• 服务级别协议（SLA）应与业务目标紧密一致

• 服务通过定制的服务目录定义和提供

• 在区域边界之外设计云级灾难恢复

战略合作伙伴

客户希望在最终阶段拥有高效、可扩展的云，其云环境具有混合能力。IT 可以作为服务通过自动化、基于策略的治理和控制来消费，覆盖整个云环境。

这也将有助于通过预测和自愈操作工具能力支持的零接触操作。应用程序的移动性和设备无关的访问是云计算的完美用例。

现在，IT 正作为任何组织的战略合作伙伴，通过以下方式提高其业务目标：

• 在满足市场需求方面提供按需帮助

• 通过减少总拥有成本（TCO）提高利用率

• 提高服务质量（QoS）将增加稳定性

• 预算和服务应相互一致

• 资源优化将提高业务敏捷性和效率

• 基于预测分析和主动行动的持续创新

• 在混合云环境中提高应用程序的适应性

• 在私有云和公共云之间实现单视图管理

• 跨不同地理区域的服务级别灾难恢复

• 智能修复和自愈过程

日志洞察的用户界面

日志洞察有两个用于日志监控和分析的界面：

• 仪表板：仪表板是日志洞察吸收的日志数据的 GUI，并包含内容包以实现更好的定制，每个仪表板有一个或多个小部件。小部件根据预构建或用户创建的查询进行定制，并附带图表来表示日志数据。

• 交互式分析：这将帮助管理员检查日志消息、定位问题区域，并从事根本原因分析。vSphere 内容包包含有关特定事件日志数据的自定义仪表板。这些仪表板将通过特定事件（如 分布式资源调度器（DRS）/HA、vMotion、安全性和不同的性能参数）提供高级概述信息。内容包通过允许快速查看环境中的问题区域来累积和显示 vSphere 环境中的相关日志数据，以找到可能的关联原因，找到根本原因，并解决问题。

内容包是 vRealize Log Insight 的只读插件，为特定事件类型（如日志消息）提供预定义的数据信息，以以特定格式提供数据，便于运维团队理解。

内容包应该回答诸如“产品/应用程序是否健康？”等问题。此外，内容包应该加深对产品/应用程序工作原理的理解。

内容包包含可以从 VRealize Log Insight 的仪表板或交互式分析页面保存的信息。这包括以下内容：

• 查询

• 字段

• 聚合

• 警报

• 仪表板

• 代理组

• 设置说明

Log Insight 能够执行实时日志管理，以在物理、虚拟和云环境中获得洞察。与 vRealize Operations Manager 紧密集成，Log Insight 提供了在动态混合云环境中主动启用服务级别和运营效率所需的运营智能和企业级可见性。

Splunk Enterprise 是 Log Insight 的竞争性解决方案，具有类似的日志管理和运营智能。Splunk Enterprise 是一种通用日志管理解决方案，密切关注机器数据以提供洞察（Splunk 称为 运营智能）。与 vRealize Log Insight 相比，Splunk 的性能受损，在执行搜索查询所需的时间和显示搜索结果所需的时间方面远远落后于 Log Insight。

索引性能、存储和报告导出

Splunk Enterprise 提供了一个分布式管理控制台，允许管理员查看有关整体 Splunk 基础设施的信息。它可以收集来自几乎任何来源的数据，并提供从网页、命令行界面（CLI）和应用程序输入数据的多个选项。管理员还可以配置高级归档和数据退役策略。

然而，当执行网络密集型操作时，Splunk 会变得远程不可访问，并且在控制台上查看报告和仪表板时存在多个问题。

vRealize Log Insight 与 vRealize Operations Manager 紧密集成，为 VMware 虚拟基础设施提供深入洞察。集成的网络负载均衡器增强了集群的可用性，有助于构建强大的解决方案。历史日志数据可以存档到 NFS 服务器，但功能有限。

用户体验

Splunk Enterprise 提供了一个统一的用户控制台用于日志管理。Splunk Enterprise 可以通过两种身份验证方法之一访问：使用轻量级目录访问协议（LDAP）身份验证或通过专有 Splunk 身份验证。Splunk 提供了多种可视化结果选项，包括报告、图表和仪表盘，但仪表盘中的饼图不显示图例值。XML 仪表板可以转换为 HTML 仪表板，但一旦创建仪表板，管理员就无法修改要显示的结果的日期和时间。此外，在配置警报的简单邮件传输协议（SMTP）服务器时，Splunk 不验证 SMTP 服务器详细信息；每次安排 PDF 报告时，它都需要与 Splunk 服务器进行测试连接。

VMware vRealize Log Insight 是一款真正简化的日志管理工具。Log Insight 简化了结果可视化、新字段提取和从搜索页面本身更改日期/时间标准。与 Splunk Enterprise 不同，Log Insight 还允许修改预配置仪表板的日期和时间值。然而，当任何已保存查询或图表的字段定义更改时，它将停止更新相应的结果。Log Insight 与 vRealize Operations Manager 无缝集成，但发送到 Operations Manager 的警报不会显示严重级别。Operations Manager 中显示的所有警报都与普通信息警报相同。这可能会给试图识别关键或重要问题的管理员造成问题。

以下截图显示了包含所有警告的仪表板：

我们通过将小部件与其他小部件链接，打开交互式分析界面，并通过查询和筛选出与特定客户相关的信息。我们还可以通过点击仪表板来链接多个仪表板，这将显示仪表板列表，以便进一步细化如何查看日志集，因为我们通过主机名小部件在 vSphere 内容包通用概述仪表板中按仪表板链接获取所有 vSphere 事件的仪表板。我们还可以在特定小部件上选择另一个仪表板，这将显示包含特定信息或问题区域的内容包所选主机的仪表板列表。

我们通过配置查询过滤器信息和时间范围来适配交互式分析。通过点击交互式分析，我们将重置概述图表和查询到默认状态。我们首先会在交互式分析页面的顶部看到概述图表，这是一个日志数据的图形界面。这是基于图表类型、查询和选择的累积函数。搜索框和查询构建器帮助用户过滤和定位相关日志信息。如果用户从仪表板视图的部件转换而来，查询标准将自动输入。底部视图显示单个日志事件。

它显示了与指定时间范围内持续存在的日志消息相关的字段。Log Insight 从日志数据中提取一个子集作为数据库中的列。这有助于查询非结构化日志数据。我们可以在字段视图中查看与特定事件相关的字段。包含在索引中或手动提取的字段是静态的。这些字段数据可以通过代理解析器、内容包字段、syslog 字段或手动提取的字段进行提取或包含。通过点击字段，在字段视图中显示一个迷你图表。

事件

吸收的日志事件可以在交互式分析中显示。默认情况下，所有日志事件都会显示，即使没有添加过滤器，也会根据以下条件提供基于事件的详细信息：

• 一旦日志消息到达 Log Insight 服务器，它就会被标记时间。

• 日志消息具有相关的字段，可以创建快速高效的查询，例如，hostname 和 appname 都在 syslog RFC 兼容字段中。

• 字段也可以通过内容包和第三方工具集成包含，例如 VMware 集成中添加的 vmw_datacenter、vmw_object_id 和 vmw_vcenter 字段。我们可以对这些字段进行查询以获取特定的日志消息。

由 Log Insight 交互式分析创建的查询：

• 创建查询：Log Insight 在搜索日志消息时辅助使用普通英语单词。我们还可以通过利用正则表达式来创建查询：

• 选择时间范围：

  • 通过列出所有选项来探索时间范围下拉菜单。

  • 检查最新的 24 小时数据：

我们可以仅显示那些时间戳在所选时间范围内的日志事件。客户端网络浏览器中设置的时间区域发现可见的日志消息。事件列表将根据最后 24 小时的日志消息进行修改。

日志消息输出与过滤器中匹配的值和运算符相关。

以下是一些获取所需输出的过滤器选项：

• 运算符管理过滤功能，就像我们以前在仪表板上做的那样。具有数值的字段，如延迟数字，有额外的运算符，如 <、> 或 =。

• 当创建两个或更多过滤器时，我们有匹配所有或匹配任何值的选项。

• 我们可以通过点击下拉箭头并滚动到所需的字段来选择一个新的字段。我们还可以在搜索框中输入过滤器，Log Insight 将根据输入的单词匹配结果。默认情况下，新过滤器有一个文本字段。

Log Insight 利用查询中的 globs。* 帮助匹配各种字符。? 仅支持一个字符，而使用 fail* 可以返回（failed、failure 或 failing）作为输出，但 erro? 主要会返回错误作为输出。Log Insight 将验证与我们输入的值相对应的匹配。OR 约束可用于单个过滤器行的多个值，例如包含 esx-03a OR esx-01a 的文本。

累积函数：我们还可以使用累积函数来管理 Log Insight 中操作概述图表的数据。默认的累积函数是按时间统计事件的数量，它显示在搜索框上方，点击下拉菜单将提供更多函数。可以在图表中包含多个函数。这有助于以两种不同的方式显示单个事件。概述图表将修改并添加控制台中主机名的唯一计数作为线条。每个列和线条都会展示信息。列将显示特定时间框架内事件的数量。线条可以提供在指定时间框架内具有匹配错误日志的主机名的数量视图。我们将按主机名和事件分组结果，信息将通过显示时间范围和特定主机名的事件计数来显示。还有其他图表可供使用，Log Insight 默认会自动选择最适合数据集的图表。我们可以手动选择图表以以不同的方式显示数据。

现在，我们将探索 vRealize Network Insight 工具，该工具提供关于所有网络数据包的端到端可见性以及它们如何从一个对象传输到另一个对象的信息，同时还提供预测分析以实现更好的规划和设计。

VMware vRealize Network Insight

VMware vRealize Network Insight 为客户提供软件定义网络和安全的智能操作。它帮助客户在不同的云基础设施上构建高效、始终在线且安全的网络基础设施。我们可以规划、设计和部署微分段，以实现虚拟和物理网络的可见性。它在管理 VMware NSX 部署方面非常有用，并且作为 VMware Network Insight 服务提供。vRNI 定期（平均每 5 到 10 分钟）以只读方式轮询第三方设备。使用的协议包括 Secure Shell (SSH)、简单网络管理协议 (SNMP) 和 表示状态转换 (REST)。

vRNI 管理员必须使用在这些设备上预先定义的只读凭据配置 vRNI 数据源接口。此外，vRNI 必须能够访问这些设备，在这些设备上没有防火墙和其他类型的网络安全限制（特定于这些协议）。特别是，SNMP 通常配置为高度限制。在大多数情况下，vRNI 代理节点，其中执行 SNMP 只读请求，通常位于本地，在同一层 2 管理网络内，与它需要轮询的第三方设备相同。

vRNI 不是实时轮询这些设备，也不是监听或收集 SNMP 陷阱或日志数据。vRNI 是一个基于时间的分析产品，并且再次每 5-10 分钟（取决于设备和用例）轮询数据，以支持该产品提供的用例。以下显示了为 vRNI 仪表板收集数据的各种方式：

• SSH：vRNI 使用 SSH 2.0 版本来访问第三方数据源。默认情况下，第三方设备每 10 分钟轮询一次（除了 Brocade VDX，每 15 分钟轮询一次）。不维护持久会话。

• REST：vRNI 还使用数据源提供的 REST API。默认情况下，第三方设备每 10 分钟轮询一次。不维护持久会话。

• REST/SSH 用户凭据和权限：vRNI 需要只读的第三方设备凭据（密码）来访问 REST 和 SSH 数据。这些密码在 vRNI 用户界面配置第三方数据提供者时添加。

• SNMP: vRNI 使用 SNMP 从第三方设备（交换机、路由器、防火墙等）收集指标信息。第三方设备必须启用 SNMP 并且可以从 vRNI 访问。vRNI 每五分钟查询一次设备以收集指标信息。

根据使用的 SNMP 版本的确切版本，需要不同的参数：

• SNMP 版本 2C：需要在交换机上配置 SNMP 社区字符串

• SNMP 版本 3：需要授权轮询交换机上 SNMP 服务的用户的全部凭据

支持的数据源

以下表格总结了 vRNI 当前支持的数据源：

数据源	版本/型号	描述
AWS（仅限企业许可证）	不适用	它通过 HTTPS 连接到 AWS。
Arista 交换机	7050TX、7250QX、7050QX-32S、7280SE-72	它通过 SSH v2 和 SNMP 连接到 Arista 交换机。
Brocade 交换机	VDX 6740、VDX 6940、MLX、MLXe	它通过 SSH v2 和 SNMP 连接到 Brocade 交换机。
Check Point 防火墙	R80	它通过 HTTPS/REST 连接到 Check Point 防火墙。
Cisco 自适应安全设备（ASA）	5x 系列（无 FirePower）ASA 操作系统版本 9.4	它通过 SSH v2 和 SNMP 连接到 ASA 设备。
Cisco Catalyst	3000、3750、4500、6000、6500	它通过 SSH 和 SNMP 连接到 Cisco Catalyst 交换机。
Cisco Nexus	5000，6000，7000，9000，VSM N1000	它通过 SSH v2 和 SNMP 连接到 Cisco Nexus 交换机。
Cisco 统一计算系统 （UCS）	B 系列刀片服务器，C 系列机架服务器，机箱，Fabric 互连	它通过 HTTPS 连接到 UCS Manager，通过 SSH 连接到 UCS Fabric Interconnect 以获取信息。它还连接到 UCS 上的 SNMP 服务。
Dell 交换机	PowerConnect 8024，FORCE10 MXL 10，FORCE10 S6000，S4048，Z9100	它通过 SSH v2 和 SNMP 连接到 Dell 交换机。
HP	HP OneView 3.0	它通过 HTTPS/REST 连接到 HP OneView Manager。
HP	HP Virtual Connect Manager 4.41	它通过 SSH v2 连接到 HP Virtual Connect Manager。
Infoblox	Infoblox	它通过 REST 连接到 Infoblox。
Juniper 交换机	EX3300，QFX 51xx 系列（JunOS v12 & v15，不含 QFabric）	它通过 Netconf 或 SSH v2 和 SNMP 连接到 Juniper 交换机。
Palo Alto Panorama	7.0.x，7.1.x，8.0	它通过 HTTPS/REST 连接到 Panorama。
VMware NSX	6.4, 6.3（至 6.3.5），6.2（至 6.2.9），6.1（至 6.1.7），6.0	它通过 SSH v2 和 HTTPS 连接到 VMware NSX。
VMware NSX T	2.0	它通过 HTTPS 连接到 VMware NSX T。

所有 REST API vRNI 使用以下：

API	描述
/api/v1/sessions	它通过 API 创建一个会话。这相当于登录。此操作将安全上下文中提供的用户凭据交换为用于后续调用身份验证的会话标识符。为了验证后续调用，客户端应包含会话密钥。
/api/v1/version	它获取 Log Insight 安装的版本。
/api/v1/content/contentpack/${id}	它获取具有给定 ID 的 vRNI 内容包的详细信息。
/api/v1/alerts	它获取与该用户对应的警报列表。
/api/v1/events	它获取在查询时间范围内发生的与内容包警报匹配的事件列表。

摘要

在本章中，我们学*了 LInt 如何作为核心服务访问 VMware Cloud on AWS 审计日志，以便更快地进行监控和故障排除，并基于自定义触发器的异常实时警报。它还将为您提供自定义仪表板，以可视化趋势，并针对自定义警报进行有效通知，在日志中进行高性能搜索以更快地进行根本原因分析。我们了解了它如何提供跨各种应用程序的单个控制台，例如 VMware Cloud on AWS、基于云的应用程序和基于原生 AWS EC2 的应用程序，以及 Wavefront 集成以实现更快的

使用日志和指标进行故障排除。我们看到了如何通过识别基础设施和应用程序中的异常来快速确定本地 SDDC 环境的健康状态，并通过 VMware SDDC 解决方案（如 vCenter 和 NSX）的即插即用仪表板加速故障排除。

在下一章中，我们将通过使用 vRealize Automation 来探索机器学*即服务（MLaaS）。ML 工作流程包括数据清洗、模型选择、特征工程、模型训练和推理。生产 ML 环境总是复杂难建且难以维护，因为每个 ML 过程可能都需要对硬件和软件进行定制。我们可以通过配置所需的操作系统和应用程序堆栈，并自动部署硬件资源（例如负载均衡器即服务（LBaaS）和网络即服务（NaaS）），将它们提供给不同的租户，从而消除这种复杂性。

第七章：云中的机器学*即服务

本章将帮助您通过使用 vRealize Automation 了解机器学*即服务（MLaaS）。机器学*工作流程包括数据清洗、模型选择、特征工程、模型训练和推理。机器学*基础设施的生产开发和管理比较复杂，因为所有机器学*过程都需要对其硬件和软件进行修改。

我们可以通过自动化硬件资源的配置、配置操作系统和应用程序包以及向相关 IT 团队提供访问权限来最小化这种复杂性。这个过程定制可以引入为 MLaaS。我们将学* vRealize Automation 如何通过 MLaaS 的用例提供 MLaaS。它还将有助于在 vRealize Automation 中设计和配置蓝图，以定义具有工作流程的过程。我们还将探讨负载均衡即服务（LBaaS）以及网络即服务（NaaS）如何消除基于硬件的网络架构中的瓶颈。

本章我们将涵盖以下主题：

• VMware 的 MLaaS 方法和其架构

• 带用例的 LBaaS

• 转换网络和安全服务

技术要求

您可以从my.vmware.com/web/vmware/details?downloadGroup=VROVA_750&productId=742下载 VMware vRealize Orchestrator Appliance 7.5.0。

私有云中的 MLaaS

机器学*帮助计算机在不进行大量编程的情况下获取知识，并且通过改进其开发，其计算和数据性能得到提升。

高性能计算和大数据应用利用虚拟化，因为它有助于支持不同的软件基础设施的并发，创建资源池，一致的研究环境，多域数据安全，问题诊断和弹性，有效的负载均衡，以及 QoS。高性能计算（HPC）和大数据合并在一起，因此机器学*可以作为服务从不同的云环境中消费。这些应用具有巨大的数据量，需要遵循数据合规性和安全策略。客户喜欢选择私有云来托管这些具有大量数据且需要更多计算资源的机器学*应用。

我们可以使用 vRealize Automation 在私有云中配置 MLaaS，以提供由 GPU 驱动的机器学*服务，为设计/高级用户提供服务。该工作流程可以帮助构建一个基于机器学*的蓝图，以满足设计用户的特定需求。

VMware 的 MLaaS 方法

我们有两个私有云选项来使用 VMware 构建基础设施即服务（IaaS）：

• vRealize Automation

• 集成 OpenStack

vRealize Automation 通过创建混合云中托管的自定义基础设施、工作负载和应用程序来帮助实现 IT 自动化。VMware Integrated OpenStack 是一个具有 VMware 直接支持的 OpenStack 发行版，帮助客户在始终可靠的 vSphere 引擎上构建企业级 OpenStack 云。它通过易于使用且供应商独立的 OpenStack API 访问 VMware 环境来提高性能。本章将简要介绍如何使用 VMware vRealize Automation 创建 MLaaS。

使用 vRealize Automation 和 vGPU 的 MLaaS

我们可以配置一个 TensorFlow 服务，最终用户可以通过使用 vRealize Automation 构建的自助服务配置门户来消费。我们已经在 vSphere、vRealize Automation、NVIDIA GRID 驱动程序中安装了 NVIDIA 显卡，以支持 NVIDIA vGPU，并在认证服务器上推荐了客户操作系统。

ESXi 上的 NVIDIA GRID vGPU Manager 驱动程序应配置为提供 vGPU。物理 GPU 应在 ESXi 中显示为 vGPU 设备，而不是默认的 vSGA 设备。

在 vSphere ESXi 上配置 NVIDIA vGPU

我们可以为最终用户构建一个 vRealize Automation 模板，让他们可以利用 TensorFlow 服务。创建和配置 TensorFlow 服务的流程在下一图中提到。为最终用户构建和配置 TensorFlow 服务的步骤将包括以下五个步骤，使用 CentOS 虚拟机：

1. 将 NVIDIA GRID vGPU 添加到虚拟机

2. 自定义客户操作系统环境

3. 将虚拟机转换为模板并创建自定义规范

4. 设计蓝图

5. 发布蓝图

在第一章，“使用 vSphere 6.7 的机器学*功能”，我们了解到前三个步骤是在 vCenter 控制台中配置的，最后两个步骤可以使用 vRealize Automation 进行配置。最后两个步骤在以下图中提到：

自定义 vRealize Automation 蓝图

首先，我们必须关闭安装有驱动程序/所有工具和配置了 vGPU 的虚拟机。我们必须将其转换为模板，这样我们就可以使用 vRealize Automation 将其作为蓝图。一旦创建了模板，我们就可以在创建了所需的模板后构建一个具有定义参数的统一自定义蓝图。云管理员可以使用此功能为 TensorFlow 虚拟机创建克隆蓝图：

1. 以管理员身份登录 vSphere web 客户端。

2. 右键单击虚拟机对象，选择模板 | 转换为模板。

3. 点击“自定义规范管理器”并基于主页上的模板创建一个新的规范。

4. 在创建虚拟机时创建一个软件堆栈，该堆栈定义了要在蓝图内安装和配置的所有软件的软件生命周期。

5. 蓝图必须设计为利用 vRealize Automation 的自定义功能：

1. 将软件堆栈捆绑在一起，以设计如何在 vRealize Automation 的蓝图虚拟机中安装、配置、启动、升级和卸载软件。我们可以在设计控制台上将此软件堆栈拖放到特定的容器变体上。

2. 通过创建软件组件来安装 TensorFlow。探索“设计”选项卡，然后选择“软件组件”，并选择“新建”。

3. 为软件堆栈定义一个名称和详细信息。在“常规”部分中，我们必须提及容器规范作为机器，然后点击“下一步”继续。

4. 创建一个命令脚本，用于获取 TensorFlow GPU 容器镜像，并自定义/etc/motd文件，以便用户登录到 TensorFlow 虚拟机时显示指令。vRealize Automation 将安装容器镜像，示例 bash 脚本类型可以根据所需的配置和安装步骤进行更改。

5. 设计蓝图。蓝图定义了使用 vRealize Automation 实施服务的流程。我们可以选择一个基本的蓝图，它只能部署单个虚拟机，以及一个多虚拟机蓝图，该蓝图具有软件堆栈、网络、安全性和存储策略：

1. 创建一个蓝图，其中只包含 CentOS 虚拟机、TensorFlow 应用程序和相关虚拟网络：探索“设计”选项卡，选择“蓝图”，并选择“新建”。

2. 在新的蓝图部分中提及名称和详细信息，以便生成一个唯一的 ID。

3. 通过从“类别”部分选择机器类型并将 ESXi 主机拖放到设计控制台，将 ESXi 主机添加到 TensorFlow 蓝图。我们必须在“常规”选项卡中定义其他参数，并提及蓝图构建的所有虚拟机名称的名称前缀，以及为用户提供最多四个 TensorFlow 虚拟机的自助配置访问权限。

4. 访问“机器资源”选项卡，以获取为该蓝图创建的虚拟机配置的虚拟 CPU、内存和存储信息。

5. 当虚拟机创建时，在“网络”选项卡下指定虚拟网络。

6. 从下拉菜单中选择所需的网络，并选择 DHCP 或静态。如果我们将一个 passthrough PCI 设备包含到虚拟机中，我们必须为此配置分配完整的内存预留。在克隆过程中，名为“虚拟机内存预留”的模板将无法保持此配置。为了管理这一点，我们必须通过探索“属性”选项卡添加特定的VMware.Memory.Reservation参数，并定义一个内存大小。

我们可以通过 vRealize Automation 服务目录中的“机器学*”类别将此蓝图作为服务进行配置，并提名用户使用它。编辑“自定义属性”选项卡，并按照以下步骤操作：

1. 在蓝图中选择 TensorFlow-GPU

2. 点击发布：

我们可以从前面的截图中的自助服务配置门户中看到带有和没有 GPU 的各种 ML/DL 服务，设计用户可以使用定义的资源。

LBaaS 概述

客户可以通过将其与 NSX 和 vRealize 自动化引擎集成来使用 LBaaS，这创建了一个包含应用程序要求的流程。他们还可以通过此服务与第三方工具集成，以实现服务的自动化部署和监控。我们有很多选项，通过使用 VMware 软件定义方法来设计作为服务的负载均衡器。

负载均衡器必须卸载 SSL 以提高性能并输出。全局负载均衡器必须在多个数据中心之间将故障转移到应用程序服务。它必须使用最有效的负载均衡算法来提高应用程序服务的效率。它可以在发现任何威胁时立即监控应用程序服务并生成警报。

VMware vRealize Orchestrator (vRO) 通过自动化 F5 虚拟服务器的部署，根据预定义的工作流（包含步骤数量、与 IP 地址关联的虚拟服务器添加、协议、端口、配置文件和特定虚拟服务器的监控报告等参数）帮助我们构建 LBaaS。LBaaS 必须提供 HTTPS 作为服务并卸载 SSL。vRO 可以在 PowerShell 服务器上执行脚本以生成由 Microsoft CA 签名的证书并将其传输到 F5 服务器。它确保 SSL 已附加到 F5 配置文件。

LBaaS 设计用例

LBaaS 应用场景如下：

• 部署单站点负载均衡器

• 部署多站点负载均衡器

• 定制负载均衡器

• 删除 VM

让我们详细看看应用场景：

• 部署单站点负载均衡器：创建虚拟机，然后使用特定的虚拟机定义负载均衡器。用户可以通过 Self-Service Portal (SSP) 登录并请求虚拟服务器。根据设计，负载均衡器在单个站点配置。用户可以通过列表框和组合框以及预填充数据来选择数据，以提供数据输入过程。vRealize 有能力调用 vRO，而 vRO 将执行预定义的工作流步骤以为用户选择的虚拟服务器组配置 F5 虚拟服务器。

  一旦 vRealize Automation 收到特定应用程序的数据，它可以使用 VMware Infrastructure Planner (VIP) 和 DNS 名称创建一个 F5 Local Traffic Manager (LTM) 虚拟服务器，并根据工作流：

步骤	参与者	操作
1	用户

1. 登录到 vRealize SSP

2. 使用 XaaS 蓝图请求 LBaaS 配置

3. 向请求表单提供必要的数据

|

2	vRealize Automation

1. 接收并验证用户输入的数据

2. 调用 vRO 工作流以配置 F5 虚拟服务器

|

3	vRO

1. 配置 F5 虚拟服务器

2. 将 F5 虚拟服务器附加到用户选择的虚拟机上

|

• 部署多站点负载均衡器:多站点负载均衡器配置与单站点负载均衡器不同，因为与 Big-IP DNS 关联的两个 F5 LTM 配置在两个数据中心。Big-IP DNS 不是必需的，仅作为全局负载均衡器需要。其工作流帮助用户在两个站点之间选择各种流量流方法（即 50/50、80/20、60/40、40/60 和 20/80）的替代方案。

  用户将数据输入到 vRealize Automation 请求表单中。vRealize Automation 将调用 vRO 工作流处理数据，创建两个 F5 虚拟服务器（每个站点一个），以及一个 F5 Big-IP DNS 系统：

步骤	角色	操作
1	用户

1. 登录到 vRealize SSP

2. 使用 XaaS 蓝图请求 LBaaS 分配

3. 选择全局流量管理器（GTM）复选框以创建多站点负载均衡器

4. 将 LTM 和 GTM 信息输入到请求表单中

|

2	vRealize Automation

1. 接收并验证用户输入的数据

2. 调用 vRO 工作流分配三个 F5 虚拟服务器——每个站点一个 LTM 和一个 Big-IP DNS

|

3	vRO

1. 提供 F5 虚拟服务器

2. 将用户选择的虚拟机与 F5 虚拟服务器关联

|

• 修改负载均衡器:可以在 F5 上使用新虚拟机自定义负载均衡器，然后我们可以执行 XaaS 蓝图到配置有负载均衡器的新虚拟机。如果用户在负载均衡器部署期间选择了错误的负载均衡器算法，他们可以通过 XaaS 蓝图进行修正。

  下表描述了此用例的操作：

步骤	角色	操作
1	用户

1. 登录到 vRealize SS

2. 使用 XaaS 蓝图请求 LBaaS 修改

3. 提供修改现有负载均衡器所需的数据

|

2	vRealize Automation

1. 接收并验证用户输入的数据

2. 调用 vRO 工作流以修改 F5 虚拟服务器

|

3	vRO

1. 修改 F5 虚拟服务器

|

• 取消分配虚拟机:我们可以使用 vRealize Automation 工作流取消分配 F5 虚拟服务器成员池中的任何成员虚拟机，否则 F5 将发布带有消息“虚拟机不可用”的警报。

  用户还可以使用修改后的 XaaS 工作流从 F5 虚拟服务器池中删除虚拟机。当最后一个虚拟机被删除时，F5 虚拟服务器成员池将自动完成：

步骤	角色	操作
1	用户

1. 登录到 vRealize SSP

2. 使用现有蓝图请求虚拟机取消分配

|

2	vRealize Automation

1. 在虚拟机取消分配蓝图部分调用 LBaaS XaaS 工作流

|

3	LBaaS XaaS 工作流

1. 接收虚拟机取消分配请求的所有必要数据

2. 调用 vRO 工作流

|

4	vRO

1. 创建 XaaS 工作流以将虚拟机添加/删除到 F5 虚拟服务器成员池

|

• LBaaS 工作流程：为了部署多站点负载均衡器，在多站点设计中每个站点部署两个相同的负载均衡器。还会创建一个 Big-IP DNS wide-IP，并要求用户输入其他输入，包括主站点和流量流比率：

** Lane**	Action	Notes
vRO	使用 REST API 的高级 F5 GTM 工作流程

1. 点击 GTM 复选框并输入 Big-IP DNS 参数以运行工作流程来构建 BIG-IP DNS 全局负载均衡器

|

下面的图显示了工作流程：

让我们逐一介绍前面图中提到的所有功能。正如我们所知，前五个步骤已经在 LBaaS 工作流程中讨论过，并且需要执行 LBaaS 工作流程。所有功能都是从参考点的角度给出的：

1. 创建一个监听器。从 Big-IP DNS UI 中选择 DNS | 交付以提供监听器参数的值。每个站点都需要创建一个监听器。这是 LBaaS 工作流程的前提条件。

2. 创建数据中心。从 Big-IP DNS UI 中选择 DNS | GSLB | 数据中心 | 数据中心列表 | 新数据中心以提供数据中心名称和其他参数。您需要为两个数据中心重复此步骤。这是 LBaaS 工作流程的前提条件。

3. 创建 Big-IP DNS 和 LTM 服务器。从 Big-IP DNS UI 中选择 DNS | GSLB | 服务器 | 服务器列表 | 新服务器以将 LTM 服务器添加到 Big-IP DNS。您需要为两个数据中心重复此步骤：主站点和辅助站点。这是 LBaaS 工作流程的前提条件。

4. 配置(bigip_add utility)iQuery：

   1. 登录到 Rancho Cordova 的 BIG-IP DNS。

   2. 运行# bigip_add <rc-ltm-ip>命令以将 Rancho Cordova LTM 添加到 GTM。

   3. 当 BIG-IP DNS 和 LTMs 之间成功通信时，BIG-IP DNS UI 中的状态将变为绿色。这是 LBaaS 工作流程的前提条件。

5. 配置 sync-group：

   1. 将 DNS 服务器（RC_DNS和FX_DNS）添加到 BIG-IP DNS 系统中。

   2. 创建 sync-group。

   3. 使用#gtm _add <fx-gtm-ip>命令将 Fairfield Annex BIG-IP GTM 设备添加。

   4. 使用#bigip_add <fx-ltm-ip>命令将 Fairfield Annex BIG-IP LTM 设备添加。这是 LBaaS 工作流程的前提条件

6. 创建全局服务器负载均衡器（GSLB）池：

   1. GSLB 池将作为 LBaaS 工作流程的一部分创建。池名称将由用户作为 XaaS UI 的一部分提供。

   2. 如果手动创建，选择 GSLB | 池。点击“创建”以创建全局池。

7. 创建 wide-IP：

   1. Wide-IP 将作为 LBaaS 工作流程的一部分创建。

   2. 如果手动创建，选择 GSLB | Wide IPs。点击“创建”以创建 wide-IP。wide-IP 名称将由用户作为 XaaS UI 的一部分提供。

   3. wide-IP 将通过从 Infoblox 的 vRO IP 保留工作流程分配 IP 地址。

网络和安全服务的挑战

网络和安全一直是基础设施的瓶颈。

以下是在刚性硬件定义的基础设施中存在的重大痛点：

• 放置和移动受到物理端口的限制

• 由于缺乏先进的自动化能力且未设计用于自动化，因此配置速度缓慢

• 它需要大量的操作和硬件依赖

为了实现 IT 即服务（ITaaS）模型，以下是可以采取的措施：

• 云网络架构和运营模型支持IT 即服务（ITaaS）模型的演进

• 实时监控和故障排除（跨越虚拟和物理网络）的端到端可见性，以实现集成网络可用性和性能管理

• 按需自动网络配置和部署以支持快速应用部署

• 新的组织模型以促进新的云/SDDC 团队和现有功能团队（应用、服务器、网络和存储）之间的协作

• 支持新操作模型和服务导向方法所需的技能

为了理解新 IT 运营模型的概念以及为什么网络和安全应该成为其一部分。

NaaS 模型的不同阶段

• 审查 ITaaS 和 NaaS 操作模型

• 确定提供和运营 NaaS 所需的各项能力

• 从运营和组织角度理解走向 NaaS 操作模型的过程

NaaS 操作模型

NaaS 是 ITaaS 操作模型的重要组成部分，它帮助客户实现特定的 IT（网络、安全等）成果。我们必须审查当前的网络和安全运营模型，包括人员、流程和技术，以及如何使用 VMware 运营转型模型和框架提供 NaaS。

我们应该首先以结构化的方法发现管理和运营 NaaS 服务所需的运营能力。

它主要关注三个主要领域：

• 积极的运营管理

• 网络和安全服务配置

• 安全操作

确定了关键运营能力，以及如何从当前的运营能力转型到支持 NaaS 愿景的网络虚拟化环境，以下是对以下各个领域的描述：

• 定义愿景和战略

• 定义关键运营能力

• 评估运营准备情况

• 制定运营转型路线图和计划

• 开发和实施具有 NaaS 愿景的目标运营模型

VMware NaaS 转型工作坊服务向客户提供了如何利用网络虚拟化架构向 NaaS 操作模型以及最终向 ITaaS 操作模型过渡的操作和组织视角。

VMware 将 ITaaS 定义为一种新的交付和运营模式，该模式利用云计算技术，通过提供价格透明、服务级别已确立的易于消费的 IT 服务，以实现业务敏捷性和基于价值的选项。网络在实现 ITaaS 愿景中扮演着关键角色。直到现在，网络被视为敏捷性和速度的障碍，但基于网络虚拟化和 SDDC 云计算的新兴网络架构，为部署、管理和运营网络和安全开辟了新的方式。

新的运营模式意味着从以设备为中心的运营模式向以服务为中心的运营模式（称为 NaaS）的转变。尽管网络虚拟化是技术推动者，但仅靠技术本身不足以实现软件定义网络（以及 SDDC 总体上）的全部好处，但它必须由简化、集成和自动化的流程以及打破壁垒的新技能的跨职能组织来补充。

这种范式转变实际上是一种超越技术方面的运营转型，它影响了运营和组织方面。运营和组织方面不应被视为事后考虑——它们应该与技术计划和平行设计和规划。

NaaS 转型工作坊旨在支持客户在愿景和战略定义阶段，以及在规划部署、管理和运营客户将要实施的网络虚拟化解决方案所需的运营和组织能力。

工作坊的目标是帮助客户理解 NaaS 运营模式，并识别网络虚拟化采用在运营和组织方面的影响和挑战，以及充分利用新兴网络架构带来的好处所需的能力。

工作坊服务还介绍了 VMware 运营转型模型和框架，以及它如何应用于推动向 NaaS 运营模式的运营和组织成熟度增长。

NaaS 服务可以分为两部分：

• NaaS 转型展望：我们必须帮助客户清晰地理解 VMware NaaS 运营模式，它在 ITaaS 运营模式中的作用，以及采用该模式在 IT 成果方面的好处。我们还将讨论客户的运营策略、目标和目标，以及跨人员、流程和技术当前的网络和安全运营模式，以及如何使用 VMware 运营转型模型和框架将其转变为 NaaS。这面向愿意探索网络虚拟化如何推动采用新的网络和安全运营模式，使 IT 更加敏捷、灵活、高效和业务对齐的网络和 IT 基础设施及运营团队。

• NaaS 转型发现：从流程角度出发，发现管理和运营 NaaS 所需的操作能力。端到端操作流程被分解为常见流程元素，并确定了执行流程元素所需的操作能力。发现活动集中在三个主要领域：主动操作管理、网络和安全服务自动化提供以及生命周期管理和安全操作。对于每个领域，都确定了关键操作能力，并对如何从当前的操作能力发展到运营一个支持 NaaS 愿景的网络虚拟化环境进行了高级观察。

通过使用 NaaS 转型传统网络：

• 传统网络挑战：网络涉及端口及其与性能、配置和定制应用特定集成电路（ASICs）功耗相关的功能。它还与相关技能集和网络操作相关的 OpEx 成本相关。如果网络服务依赖于特定的物理设备并采用手动部署，则不会具有敏捷性，这会增加配置更改和人为错误的风险。为每个设备接口编写脚本以编排自动化是不合理的，因为它阻碍了利用虚拟化和云模型全部功能。

• 网络是一种服务：它始终是，并将继续通过抽象化、创建资源池和自动化网络来提供一种服务。网络服务可以即时从容量池中提供，与特定硬件解耦，实现同等移动性，使用模板部署，并通过策略进行控制和管理工作。NaaS 运营模式使我们能够提供未来的敏捷数据中心，满足现代应用程序所需的服务速度和敏捷性，以及我们期望的 OpEx 和 CapEx 效率和成本节约。

使用 NSX 进行 LBaaS 网络设计

VMware NSX 可以帮助我们构建基于Virtual Extensible LAN（VXLAN）的虚拟网络自动化部署，以在不同的 Web、应用程序和数据库服务器之间实现微分段。将配置一个Distributed Logical Router（DLR），以启用利用 NSX 逻辑交换机产生的网络之间的路由。由于 DLR 支持多达 1,000 个逻辑接口，因此可以将多个应用程序的逻辑交换机连接到 DLR，以利用其路由功能。

可以使用 NSX 服务组合器的功能，如安全组和安全策略，提供应用层分段。BIG-IP DNS 通过原生智能帮助维护应用程序冗余。在两个地点部署的两个 BIG-IP DNS 系统将作为一个单一单元工作，但负责主和辅助权威名称服务。

根据定义的规则，如资源冗余、服务级别协议（SLA）、负载、地理位置或服务质量（QoS），用户从站点 A（主）或站点 B（辅助）获取最合适的 IP 地址（即 LTM VIP）。

当广泛使用A类型查询时，BIG-IP DNS 协助处理各种类型的查询。一个 BIG-IP DNS 通过匹配域名和类型与广域 IP 来获取查询，然后选择一个池（GSLB 池）来确认响应。然后，它通过响应一个 IP 地址从池中获取虚拟服务器。GSLB 池将帮助根据每个站点的负载均衡策略和运行时的资源可用性，在两个站点之间选择虚拟服务器。

BIG-IP DNS 高级设计

广域 IP 是一个完全限定域名（FQDN），用于获取应用程序 URL，这是一个托管在多个 Web 服务器（如 Apache 或 IIS）上的 Web 应用程序。BIG-IP DNS 通过将查询解析为与广域 IP 关联的虚拟服务器（VIP）来定义广域 IP FQDN 的关联，该虚拟服务器来自具有每个站点两个虚拟服务器的全局负载均衡（GSLB）池。

LTM 虚拟服务器和 BIG-IP DNS 虚拟服务器的负载均衡器算法不同，LTM 虚拟服务器的负载均衡器算法由用户从下拉字段中选择。BIG-IP DNS GSLB 池算法由用户输入定义。LBaaS 设计选择了三种 GSLB 池算法：全球交付、比例和轮询。

定制 BIG-IP DNS 组件

BIG-IP DNS 配置包含以下组件：

• 监听器：这是 BIG-IP DNS 对象，它操作并响应 DNS 查询。在执行 LBaaS 工作流程之前，应在 BIG-IP DNS 上定义监听器配置。

• 数据中心：这是一个容器对象，用于托管应用程序交付组件，并且每个站点有两个 LTM 虚拟服务器。在执行 LBaaS 工作流程之前，应在 BIG-IP DNS 上定义数据中心配置。

• 服务器：这是一个容器对象，应用程序组件驻留其中，可以是 BIG-IP DNS、LTM 服务器或物理服务器实例。在执行 LBaaS 工作流程之前，应在 BIG-IP DNS 上定义服务器配置。

• 虚拟服务器：虚拟服务器在物理服务器上配置了 IP 地址和服务端口。BIG-IP DNS 使用这些 IP 地址和服务端口来解析查询并选择合适的虚拟服务器。

• 池：这是一个在 BIG-IP DNS 系统上配置的逻辑对象。虚拟服务器可以设置不同的池以智能地解决查询。可以通过分组所有相关的虚拟服务器来创建 GSLB 池。LBaaS 的池配置将根据 LBaaS 工作流程按需定制。

• 广域 IP：这是一个逻辑容器，通过分组 GSLB 池和所有相关的虚拟服务器而被称为 FQDN。此对象在 LBaaS 工作流程中开发和定制。FQDN 的 IP 地址将通过利用 vRO 工作流程在 Infoblox 上受到限制。

• DIG: DNS 解析实用工具是一个用于实验宽 IP 配置的工具，可以下载到系统中。用户喜欢将实用工具下载到 PowerShell 桌面，以检查 LBaaS 工作流程中宽 IP 配置的接受情况。#dig @listener-ip wide-ip-name命令将向监听器发送 DNS 查询，并显示 BIG-IP DNS 的响应。

BIG-IP DNS 负载均衡算法

我们基于 LBaaS 设计有三种类型的负载均衡算法，我们将在下面探讨；它们应该有效地注册到 BIG-IP DNS GSLB 池中。

全球可用性

此负载均衡算法适用于活动/备用场景，BIG-IP DNS 将 DNS 名称解析请求分散到配置列表中的第一个可访问虚拟服务器，如果虚拟服务器不可访问，则 BIG-IP DNS 将请求发送到配置列表中的下一个虚拟服务器。

当用户在 XaaS 表单中选择活动/备用时，vRO 工作流程应将 GSLB 池负载均衡算法定义为全局可用。它还确保第一个可到达的虚拟服务器来自活动站点。

比率

LBaaS 工作流程必须管理两个站点之间的流量。BIG-IP DNS 的比率负载均衡算法可以帮助您满足此用例。比率负载均衡方法通过使用加权轮询在池中的虚拟服务器之间分散 DNS 名称解析请求。两个虚拟服务器的权重应在 vRO 工作流程中测量并通过使用 REST API 进行注册。我们可以在 XaaS 表单中选择比率作为用户从下拉列表中的一项。

轮询

LBaaS 工作流程可以通过保持两个站点的活动状态来分配入站请求。可以配置 BIG-IP DNS 轮询算法用于 GSLB 池。BIG-IP DNS 名称解析请求可以在 GSLB 池的虚拟服务器之间按顺序分配，这样每个虚拟服务器都将获得相似数量的请求。

LBaaS LTM 设计

LBaaS 设计曾假设 BIG-IP 虚拟版本在两个站点都安装了。它还假设设备服务集群（DSC）可以在每个 BIG-IP 设备的活动/活动场景中使用。LBaaS 设计还理解，同步故障转移设备配置在虚拟版本对中持续存在，以便在成员对之间同步设备配置，这样设备就可以相互故障转移。

配置 BIG-IP LTM 对象

以下对象是通过 F5 LTM 中的 LBaaS 工作流程自动配置的：

• 节点：它代表网络中物理或虚拟实例的 IP 地址，例如 Web 服务器或应用服务器。单个节点可以运行许多应用程序服务，这些服务与池成员关联的不同或相同类型的服务。

• 池成员：它是 IP 地址和端口号的联合，定义了位于节点上的应用程序服务。池成员是通过 BIG-IP 系统获得的。

• 池：通过分组一个或多个池成员并选择合适的池成员，可以实现负载均衡。应在具有特定池成员的池上配置负载均衡策略。

• 虚拟服务器：它是一种监听器，允许匹配由虚拟服务器 IP 和端口组成的流量类型，并根据负载均衡策略将它们转发到池成员。由于 F5 LTM 是默认拒绝系统，所有流量都会被阻止。虚拟服务器是连接客户端的理想单元。

设计 LTM 负载均衡方法

我们可以使用 LTM 虚拟服务器流量操作配置许多负载均衡技术。用户会得到一个下拉框来选择以下负载均衡技术之一：

• 轮询（默认）

• 最少连接数

• 加权最少连接数

• 比率

• 观察

• 动态比率

• 最少会话数

• 最快

• 预测性

下面的屏幕截图显示了 LTM 选项卡：

设计 LTM 虚拟服务器

VMware Cloud on the AWS L2 网络扩展服务通过创建具有单个广播域的子网，使用 SSL VPN 隧道（L2VPN）将本地网络扩展到 VMware Cloud on AWS 上的任何 IP 网络上，为用户提供扩展本地网络的能力。这使客户能够在不更改 IP 地址的情况下，在本地网络和 VMware Cloud on AWS 之间迁移工作负载。

此服务从介绍其产品开始，收集详细信息以执行技术差距分析和推荐，这有助于客户为 L2 网络扩展准备环境。配置 VMware Cloud on the AWS 环境，并执行扩展网络功能测试。

本服务倡议的目标是执行以下两项活动：

• 在本地和 VMware Cloud on the AWS 网络之间建立 SSL 隧道（L2VPN）

• 使用 SSL 隧道在本地和 VMware Cloud on AWS 网络之间扩展 L2 子网

摘要

我们可以从各种基于云的服务中选择，包括 SaaS 和 IaaS。机器学*即服务（MLaaS）是 IT 行业最新的创新之一。ML 部署基本上需要大量的数据和能够从数据量中调查模式的高级用户。ML 算法始终是一种试错场景。MLaaS 将在 AI 采用中发挥关键作用，因为它将帮助开发者和企业获得 ML 特性的好处。它将帮助将 AI 嵌入商业应用程序，并使组织能够以更好的方式使用数据来实现其商业目标。

VMware SDDC 产品和方法可以用于自动化各种服务，不仅限于 VMware 提供的产品，甚至包括第三方工具。使用 vRealize 产品提供和取消提供服务的整个流程可以与 vRealize Orchestrator、vRealize Log Insight 以及运行在 vSphere 虚拟机管理程序之上的 NSX 一起自动化。

下一章，第八章，基于 Skyline 的机器学*规则引擎，将为您详细概述 VMware Skyline。我们将从客户那里收集信息，并使用机器学*作为智能规则引擎来监控并提供主动支持，通过预防即将到来的威胁来加快问题的解决速度。

第八章：基于 ML 的 Skyline 规则引擎

本章将向您展示 VMware Skyline 如何从客户那里收集信息，并使用机器学*技术创建智能规则引擎。这被用于监控异常行为，然后拉响警报以启用主动支持。

您将学*如何创建策略和规则以避免未来事件并最小化停机时间，您还将了解 Skyline 工具的功能和配置。此工具能够自动化监控和管理，以防止未知威胁的攻击。

在本章中，我们将涵盖以下主题：

• 主动支持技术

• Skyline 收集器概述

• 客户体验改进计划

技术要求

您可以从 my.vmware.com/web/vmware/details?downloadGroup=SKYLINE10&productId=790&rPId=26633 下载 VMware Skyline 收集器 2.0.0.2。

主动支持技术 – VMware Skyline

VMware 全球服务构建了一个名为 Skyline 的智能支持引擎，无需任何人工努力或妥协安全策略即可收集与客户特定的 VMware 产品相关的数据。它聚合并分析这些数据，以帮助支持团队快速解决问题并采取措施预防即将出现的问题。

我们可以从部署和使用的角度获得客户环境中 VMware 产品的全面 360 度视图。我们可以通过提供更多信息并允许他们与所有客户端点互动来概述已知和未知的问题。Skyline 对于在 VMware 基础设施上运行的至关重要的应用程序是必要的，该基础设施全年 24/7 可用，并且高度优化以从其资源中获得最大性能。客户希望快速解决问题和建议，并拥有所有支持数据分析以在客户环境中产生问题之前识别问题的数据。Skyline 可以通过其智能支持系统处理所有这些要求，该系统帮助支持工程师了解有关特定客户 VMware 产品部署的信息和数据。

如果我们像客户一样了解他们的环境，那么我们就能提前提出关于未来可能发生的问题的主动、规范和预测性建议。这也有助于支持团队处理他们的反应性支持案例，因为这些案例可以更快地解决，帮助客户更快地回到业务中。VMware Skyline 由三个技术组件（收集器、规则引擎和顾问）组成。全球服务拥有创新的新支持功能。

使用 VMware Skyline 提供的主动支持具有许多好处，包括以下内容：

• 定制的支持体验将加深与客户的联系

• 了解客户使用情况将使应用采用和价值实现通过客户成功计划

• 更快、更高品质的支持解决

• 为特定客户实施提供最佳设计、配置和软件版本

• 通过提供持续的增量价值，提高了可靠性，并具有高级预警系统

• 支持请求（SR）偏转以在发生之前修复已识别的错误

• 缩短了解决时间；也就是说，数据是主动收集的，并提供了解决方案，以便更快地进行诊断和解决

• 通过提供持续的增量价值，保护了在支持和订阅服务（SnS）预订中的大量资金

• 增加总交易规模和补偿，并将客户从生产支持升级到高级服务

• 改进工具和技术

• 了解客户环境

收集者、查看者和顾问

Skyline 收集器帮助在接*实时的情况下收集有关更改和事件详情，并且与客户环境隔离，因为收集器中不保存任何特定客户数据。VMware Skyline 数据由 VMware 支持团队根据需要访问。

VMware Skyline Advisor 将是一个面向客户的自助式仪表板，作为 SaaS 应用程序提供给客户。这将提供有关已识别警报和建议操作的详细分析，以便客户可以配置智能修复。顾问可以利用并与查看器连接，以充分利用基于策略的分析引擎，该引擎由支持智能库、产品信息和分析内部客户特定产品部署数据的逻辑组成。这用于获取建议和详细报告，可以与客户分享。它与 VMware 验证设计、最佳实践和 知识库 (KB) 文章良好集成，以发送警报、识别故障和问题以及任何偏离推荐设计的情况。然后，它通过支持工程师的支持协助启动修复过程，或者可以通过自助步骤解决故障和问题。Skyline 有一个单独的收集器实例来收集和传输与 VMware 产品相关的信息回 VMware 分析云 (VAC) 基础设施。拥有活跃产品支持的客户可以使用 Skyline 收集器。它可以使用机器学*引擎分析与特定信息（如故障）相关的更改、活动和模式。Skyline 策略引擎支持智能库、产品信息和相关逻辑，以分析与 VMware 产品相关的客户内部数据流。如果客户未遵循 VMware 验证设计实践进行配置或补丁管理，它将发送通知。所有识别的问题都会输入到分析引擎中，该引擎有数百个检测策略，帮助我们为多个客户纠正同一类问题。

VMware Skyline 在客户环境中收集有关 vSphere 和 NSX 的信息。它可以分析来自 vSphere 和 NSX 的遥测信息。我们计划在未来快速添加对更多 VMware 技术的支持，vSAN 就是我们的下一个路线图项目。最终，整个产品堆栈都将可在 VMware Skyline 上使用。随着时间的推移，我们的洞察力将不断提高，增加更多预测性建议以减少停机时间和性能问题。随着规则引擎在范围和复杂性上的发展，VMware Skyline 将不断成熟，因此对客户的价值将持续增长。客户还可以添加和删除单个产品部署以进行收集。Skyline 通过 VMware 管理访问计划免费提供给具有 vSphere 和 NSX 境内环境的 premier 支持客户（关键任务、医疗关键和业务关键）。

发布策略

VMware 的计划是提供增量收益，并扩大产品和解决方案意识的范围，以推动在开发和发布路线图中引入客户自助服务机会。

这将帮助我们快速增加价值，因为我们将为支持工程师引入 VMware Skyline Viewer，该工具将在与客户的主动和被动支持互动中使用。我们计划将 VMware Skyline Advisor 工作台提供给各个支持团队以及产品工程团队，以便他们能够积极参与新规则和分析的创建，随着我们自动检测已知问题或建议的能力的扩展。VMware Skyline 还将为未来拥有生产支持和 Premier Support Services 的客户提供额外的支持服务能力，以自助解决方案的形式提供。

VMware Skyline 符合全球服务部门的整体愿景，因为 VMware 致力于为客户提供最佳级别的支持，正如我们高客户满意度和净推荐值（NPS）所体现的那样。随着竞争试图缩小这一差距，我们进行创新。VMware Skyline 是我们那些在被动和主动支持方面使我们在竞争中领先的创新之一。没有其他全栈软件公司提供这种级别的功能。VMware Skyline 专注于转变客户体验，而我们实现这一目标的关键方式是通过建立客户亲密关系。如果我们了解并理解客户在做什么，我们就可以更积极地与他们互动，以便提供帮助和指导。

VMware Skyline 可以在非常大的客户环境中分阶段推出，也可以在初始推出期间进行。最好是从单个 vCenter 收集数据，让客户对我们提供的价值进行反馈，然后逐步增加。在现实世界中，我们可能会遇到一些我们在测试中永远不会遇到的可扩展场景，我们可以通过一个有计划的采用计划来识别这些场景。我们不推荐对初始企业软件部署采取任何激进的策略。收集器会附着到 vCenter 上。它也可以连接到多个 vCenter，但它始终可以根据每个 vCenter 进行分割。非常大的、多 vCenter 的环境也将需要为每个位置设置多个收集器。从后端来看，数据是相互关联的，因此我们知道它们都来自同一个客户。

在任何时间点，客户都可以选择退出客户体验改进计划（CEIP）。客户可以从操作中注销 Skyline 收集器并从其环境中禁用所有 Skyline 功能。收集的数据将保留 13 个月，用于客户可识别信息，对于其他收集的数据，最多保留四年。产品相关数据将保存并用于不同的流程，同时确保这些数据的安全性和端到端安全性。我们可以根据需要管理数据并去标识化。我们可以在存储和传输过程中加密数据，以及所有类型的物理安全，如防火墙、HIPS、IDS 等。我们还可以为此数据设计数据备份、灾难恢复和其他安全流程，并进行适当的审计。VMware 负责管理收集的数据，以提供更好的技术支持，以及产品增强。

我们必须满足条件才能访问 VMware Skyline 产品使用数据。这包括完成产品使用数据政策的培训，承认你对如何使用这些数据的责任，并提交一个正式请求，以识别我们预期使用的其他详细信息。该流程将继续由我们的经理进行审查，在特殊情况下，由数据受托人进行审查。如果您的请求获得批准，则可以在批准的系统（s）上配置您的访问权限。我们计划将请求流程扩展到企业身份访问管理系统。这将是我们可以与客户分享的面向外部的网站的一部分。

客户可以通过以下简单步骤下载 Skyline 收集器：

1. 点击my.vmware.com/web/vmware/details?downloadGroup=SKYLINE10&productId=790&rPId=26633链接访问 VMware Skyline 下载网站：

2. 使用您的凭据登录 Skyline 收集器：

3. 一旦您接受了 Skyline 的隐私政策，您就可以开始安装收集器设备。

4. 使用 My VMware 凭据和权限账户信息填写几个简单的配置网页，以注册收集器并学*基本设置。

Skyline 收集器概述

Skyline 收集器以虚拟设备的形式提供，可以从客户环境中收集关于 vSphere 和 NSX 的关键信息，以便支持团队能够提供更好的支持。

注册后，客户将享有以下好处：

• 通过 CEIP 获得更好的支持。

• 使用这种明确的方法，客户的数据将安全可靠。

• VMware 的 My VMware 客户门户将验证客户的身份有效性。

• My VMware 客户账户将与 Skyline 收集器设备集成。

• 客户账户验证后，客户将有权使用 Skyline 服务。

• 通过客户直接连接到 VMware 的技术支持服务，改善了客户支持体验

Skyline Collector 的要求

安装 Skyline Collector 有一些系统先决条件，包括硬件和软件配置。

软件要求如下：

• vCenter Server，6.0 或更高版本

• ESXi，v6.0 或更高版本

• NSX for vSphere，6.1 或更高版本

我们可以在满足所需最低系统先决条件的任何系统上部署 Skyline Collector。以下是 Skyline Collector 虚拟设备的先决条件：

vCPUs 数量	内存	磁盘空间
2	8 GB	87 GB（如果为精简配置，初始为 1.1 GB）

网络需求

外部网络连接要求如下：

机器	连接到	连接类型	协议	端口
VMware Skyline Collector	vcsa.vmware.com	HTTPS	TCP/IP	443
VMware Skyline Collector	vapp-updates.vmware.com	HTTPS	TCP/IP	443

大多数客户希望数据被清理，VMware 为用户提供了一个内部日志清理脚本。它从客户日志中移除 IP 地址、主机名等，取而代之的是添加一个占位符，并向客户提供密钥，以便将 IP 地址和主机名与日志中插入的名称关联起来。此功能需要包含在 Skyline 设备中，以便客户的主机和 IP 数据不会传输。如果客户不是所有数据都需要清理，他们可能希望对不同的数据有一些控制（例如单选按钮或复选框）。以下表格总结了 Skyline 操作所需的所有端口和协议：

机器	连接到	连接类型	协议	端口
VMware Skyline Collector	vCenter Server	HTTPS	TCP/IP	443
VMware Skyline Collector	平台服务控制器（PSC）/单一登录（SSO）服务提供商 5.5	HTTPS	TCP/IP	7444
VMware Skyline Collector	PSC/SSO 服务提供商 6.0 / 6.5	HTTPS	TCP/IP	443
VMware Skyline Collector	NSX Manager	HTTPS	TCP/IP	443
Web 浏览器	Skyline Collector 管理界面	HTTPS	TCP/IP	443
Web 浏览器	Skyline Collector vCenter 服务器管理接口（VAMI）	HTTPS	TCP/IP	5480

Skyline Collector 可以使用不同的网络连接来获取和传输相关数据。以下图表说明了端口的工作方式：

Skyline Collector 用户权限

Skyline Collector 的管理账户将验证并登录到 Skyline Collector 管理界面，然后注册应用程序以管理收集端点。管理账户的密码将在部署开始和收集器注册时定义。当用户被通知有挂起的更新时，Skyline Collector 的 root 用户将用于通过 VAMI 接口访问https://<Skyline_Collector_Appliance_IP_Address>:5480进行更新。

Skyline Collector 需要具有只读用户访问权限来连接到安装在客户场所的 VMware 产品（带有许可信息），以便它可以收集数据并将其与其相应的部署关联起来。

它需要在所有相关的 vCenter Server 实例中有一个用户账户，并具有以下权限：

• 收集器可以与默认的 vCenter Server 集成，具有内置的只读访问权限

• 需要全局|许可权限

Skyline Collector 需要具有审计员（或与 API 相同的访问权限）的只读访问权限，以便向 NSX Manager 发送查询。以下图表显示了认证过程的工作原理：

Skyline Collector 以开放虚拟化设备（OVF）格式提供，可以通过 vCenter 控制台中的 OVF 部署向导进行安装。虚拟设备由预配置的 VM 组成，其中预装了客户操作系统、应用程序和其他相关软件。我们可以在安装后通过包含与设备关联的 IP 地址或主机名，通过网页浏览器访问收集器管理界面。

集成客户端插件：客户端插件通过 vSphere Web Client 提供对收集器控制台和其他 vSphere 功能的访问。此插件还通过 vSphere Web Client 使用 Windows 会话身份验证帮助安装其他虚拟设备。

Skyline Collector 设备：我们可以开启收集器设备，然后访问管理界面并获取收集器设备的 IP 地址，以便探索收集器控制台：

在为特定客户环境配置之前，Skyline Collector 应该进行注册。

VMware Skyline Collector 管理界面

在启动 Skyline Collector 设备后，我们可以获取该设备的 IP 地址。这可以通过以下方式完成：

1. 作为管理员，登录到 vSphere Web Client

2. 右键单击收集器虚拟设备并选择电源。然后，点击开启

3. 在虚拟设备启动后，我们可以通过刷新 vSphere Web Client 中的摘要选项卡来查看收集器设备的 IP 地址

4. 通过网页浏览器浏览到https://<Collector_Appliance_IP_Address>

Skyline Collector 管理员界面：由于收集器证书与环境的主机名/IP 地址不匹配，我们首次连接时会出现浏览器安全警告。首先，我们必须使用默认用户名和密码登录：

我们默认的用户名是admin，密码也是default。密码应至少包含八个字符，包括一个大写字母、一个特殊字符、一个数字和一个小写字母。

在为管理员账户输入新密码后，请点击“更改”。更改密码后，我们必须再次登录 Skyline Collector 管理员界面；我们将看到“您的密码已更改成功！”的屏幕。

连接始终是单向的，从 Skyline Collector 向外连接到 VAC 或 Photon OS 更新库服务。我们有两种方法将数据返回到 Skyline Collector 设备。这可以通过 Photon OS VAMI 界面进行产品更新/补丁等操作，以及通过清单更新，我们可以发布一个更新的清单，描述已收集的数据、收集间隔等。设备会定期检查清单更新，当有更新可用时，它会下载新的清单以利用其当前配置。收集器必须通过互联网将加密数据上传到 VMware。如果收集器需要 HTTP 代理来访问互联网，请将开关切换到“是”并配置代理管理员所需的设置。点击“测试连接性”以验证网络的连接性，然后点击“继续”。

首次登录时，收集器不会被注册。要配置数据收集，需要注册收集器。首次登录时，注册向导将自动出现。

使用 My VMware 账户链接

我们可以在注册 Skyline Collector 并初始化其过程中参与 CEIP。Skyline Collector 数据在 CEIP 的支持和产品改进方面得到了广泛的应用：

然后，选择“同意并继续”。收集器注册需要一个连接到活动 VMware 生产支持或高级服务支持的 My VMware 活动账户。输入您的 My VMware 账户电子邮件、密码和权益账户 ID。准备好后，选择“链接账户”：

一旦收集器成功验证了您的凭据，请点击继续。如果客户在 My VMware 账户登录时遇到问题，请访问my.vmware.com重置账户凭据。您可以从系统状态页面的概览部分获取 Skyline Collector 和所有相关数据端点的健康报告。我们可以通过收集器部分通过重启、停止或注销来管理收集器服务。它还将显示用于注册过程的 Skyline Collector ID 和 My VMware 用户。Skyline Collector ID 是每个 Skyline Collector 实例的特定标识符，用于识别数据传输回 VMware：

我们还可以自定义 Skyline Collector 的名称，以便我们可以识别与 Skyline Collector 实例关联的权益编号和支持类型（生产/高级服务）；这样，我们可以连接到 VMware 全球支持服务团队。此权益账户将 Skyline Collector 数据连接到其相应的支持请求。这些权益账户可以通过my.vmware.com访问和驱动，Skyline Collector 日志活动可以通过管理界面实时显示。

管理端点

Skyline Collector 与 vCenter Server 集成，每个 vCenter 实例将配置三个端点。这些端点在系统状态选项卡中显示，包括所有端点的健康状态：

以下数据是从 vCenter 端点收集的：

• VC_CHANGES 端点获取 vCenter 拓扑和配置数据

• VC_EVENTS 端点获取 vCenter 事件相关数据

• VC_HOSTS 端点从 vCenter Server 获取 ESXi 事件数据

Skyline Collector 与 NSX Manager 集成，每个 NSX Manager 都配置了三个端点：

以下是对每个端点的描述：

• NSX 端点获取 NSX 产品和配置相关数据

• NSX_TELEMETRY 端点获取 NSX 操作参数，如 CPU、内存和磁盘

• NSX_EVENTS 端点获取 NSX 事件相关数据

所有端点将显示与 Skyline Collector 集成的相关 VMware 产品实例以及关联的账户，该账户读取由特定收集端点检索的所有最*和过去的数据。所有活动收集端点将以绿色显示，而出现故障的被动端点将以红色显示。

配置 VMware Skyline Collector 管理界面

所有管理操作都可以通过点击 VMware Skyline Collector 管理界面上方的配置来完成。

我们可以添加/删除用于数据收集的 vCenter Server，也可以添加/删除用于数据收集的 NSX Manager。我们可以从同一控制台配置自动升级并设置收集器的名称。此控制台还有助于配置 Active Directory 身份验证，并且 NSX for vSphere 必须设置具有这些权限的账户。

自动升级

VMware Skyline 收集器具有自动升级虚拟设备的能力。自动升级将按照计划检查和安装更新。正如我们在 VMware Skyline 收集器注册阶段所提到的，我们可以获取电子邮件通知。每次自动升级后，选择设置升级。

您可以转到配置以启用和保存我们已配置的自动升级设置：

您必须启用“启用收集器自动升级”选项或遵循以下步骤，使用 VAMI 将 Skyline 收集器设备更新到最新版本：

1. 打开网页浏览器并浏览到https://Skyline_Collector_IP_address:5480：

1. 使用 root 用户名和密码登录：

1. 选择 更新

2. 选择检查更新

3. 如果有新的更新可用，选择安装更新

CEIP

参与 VMware CEIP 是必要的，并且是 VMware Skyline 的一部分。作为初始 Skyline 收集器注册过程的一部分，必须加入此程序。Skyline 收集器会将数据发送回 VMware，以支持与特定产品实例连接的相关产品端点，以便通过 CEIP 快速支持，这包括在初始配置期间或在安装后的配置页面中。客户可以通过注销流程选择退出此程序。

收集的信息类型

VMware 产品/服务的技术数据包括以下内容：

• 配置数据：从设计和配置的角度来看，每个客户的基础设施都是独特的，即使使用相同的 VMware 产品和服务的。它们有自己的用例，根据其业务目标，数据包含有关产品的版本/版本、部署相关信息、设置以及连接到这些产品和服务的所有设备的日志数据。

• 功能相关数据：客户以各种方式部署具有其功能的产品，以便客户可以针对其各自的客户领域实现特定的业务案例。

• 性能数据：这包括有关产品和服务的所有相关信息，以及所有相关的支持报告，例如性能和扩展参数、用户界面的响应时间以及 API 调用相关信息。

• 产品日志数据：它们有与从安装阶段到生产阶段的产品产生的相关产品日志。这些日志包含有关系统活动的详细信息。这还将有助于实时生产数据的实际状态，不包括最终客户应用程序数据。

产品使用数据利用

与产品相关的数据在得到适当客户通知的情况下，被安全地管理和用于某些内部场景。这也得到了信息治理执行委员会的同意和接受。与产品相关的数据可用于不同的目的，包括以下内容：

• 产品部署报告：我们可以将客户的实际产品采用情况与购买的产品许可证相关联。账户经理只能评估此报告，以便他们可以与客户进行富有成效的讨论，并通过增强其设计和设置，以最佳方式使用购买的产品。

• SDDC 分析：这用于分析 SDDC 产品在客户基础中的部署。这可以用来识别符合特定 SDDC 部署标准的客户，这些信息可以提供给 VMware 高级管理层。

• 针对新 SDDC 产品发布的客户倡导调查：这用于识别已部署新 SDDC 产品发布的客户。这些客户可以通过高级管理层联系，以请求他们对特定客户调查的回答。

• 客户支持：技术支持工程师可能使用 VMware 许可证密钥和派生的客户 ID 值来联系客户，以便帮助解决特定的支持请求或根据产品使用数据的分析，主动提供客户可能遇到的支持问题的建议。

• 客户档案和高级分析：这用于分析客户与 VMware 的互动，以便创建客户档案和高级分析模型。这些必须仅提供给 VMware 管理层，并需要产品使用数据受托人的批准。

我们可以在产品文档中找到关于 VMware Skyline 部署架构的详细信息，特别是在包含内部防火墙的客户环境中，这些防火墙将客户网络的不同部分隔离开来，每个部分都包括 VMware 产品。这涵盖了客户网络内部和通往互联网/VAC 目的地的通信的方向连接和网络端口要求。我们不会记录收集器的北向和南向 API，这些 API 用于与它们收集的产品以及 VMware Cloud 进行通信。我们用于将数据传输回 VAC 的 API 可以在 VAC confluence 页面上找到。

VMware Skyline 旨在实现数据单向返回到 VMware，并确保架构已开发以允许向收集器返回闭环反馈以及返回到产品。连接始终是从 Skyline 收集器向外到 VAC 或 Photon OS 更新库服务单向的。我们有两种方法向 Skyline 收集器设备提供返回数据：

• 通过 Photon OS VAMI 接口，用于产品更新/补丁等。

• 通过显式更新，我们可以发布一个更新的清单，例如描述收集了哪些数据、以什么间隔等。

设备定期检查清单更新，当有更新可用时，它会拉取新的清单以利用其当前配置。系统将尝试识别主机或虚拟机级别是否启用了分布式防火墙（DFW）规则，以便更好地在出现连接问题时进行故障排除。Skyline 收集器使用安全的协议通过 HTTPS 或 SSH 将收集到的产品使用数据传输回 VMware。加密算法用于将 Skyline 收集器数据传输回 VMware。

Skyline 会随着时间的推移自动从产品 API 和客户的库存中提取遥测信息，以便我们可以识别变化、模式和趋势。这将帮助我们缩短解决问题的时间，并在问题变成服务可用性、性能或补丁/安全问题时提前发现。Skyline 收集的数据存储在美国的 VAC 中，这些 VAC 仅由 VMware 运营。Skyline 使用协议和加密的快照。通过 TLS 1.2 进行上游加密，使用加密套件TLS_RSA_WITH_AES_128_CBC_SHA256。根据政策指南，收集的数据在 VAC 和操作摘要报告（OSRs）中保留 13 个月。

摘要

VMware Skyline 能够显著改变我们对客户环境的可见性的突破性功能具有许多好处。如果我们了解并理解我们的客户在做什么，我们可以更积极地与他们互动，以提供帮助和指导。我们可以开始关注支持他们的核心问题，这样我们就不仅依赖于客户描述的症状。这推动了我们在建立和加强这些关系时的信心。在 VMware Skyline 的核心是关注改变客户体验，而我们能够做到这一点的关键方式是通过建立客户亲密感。我们可以开始关注这些可靠数据下的客户核心问题，而不是仅仅依赖于症状或客户的输入。

下一章，第九章，使用 vRealize Code Stream 的 DevOps，将为您提供一套详细的架构设计，该设计使得应用和平台能够在 VMware vRealize Automation 私有云平台上部署，并使用持续集成（CI）和持续****交付（CD）流程，以及VMware vRealize Code Stream（vRCS）和其他行业标准产品。架构设计建议将基于 VMware vRA/vRO/vRCS 产品参考架构和行业最佳实践，以及客户特定的需求和业务目标。

第九章：使用 vRealize Code Stream 进行 DevOps

DevOps 运营模型及其支持 CI/CD 工具集的实施方法正在改变 IT 资源的角色和责任，以及传统的设计、交付和运营流程。本章将使您能够进行必要的流程变更，以采用 DevOps。我们将探讨最高优先级的流程，以转换并应用技术，比较和对比传统运营模型、流程和团队结构与 DevOps 所需的战略运营模型之间的关键差异。我们还将介绍VMware vRealize Code Stream（vRCS）及其在 DevOps 发布流程和持续应用交付中的编排。

您将了解私有云的 DevOps 云运营模型，该模型通过利用 VMware 云自动化服务以及如 Puppet 之类的配置管理工具，使开发者能够无缝地部署、配置和管理生产就绪的应用程序，从而加速 DevOps 操作。您还将了解与VMware Kubernetes Engine（VKE）的 CI/CD。

在本章中，我们将涵盖以下主题：

• 应用开发生命周期

• 使用 vRealize 进行自动化

• vRCS

技术要求

您可以从my.vmware.com/web/vmware/info/slug/infrastructure_operations_management/vmware_vrealize_code_stream/2_x下载 VMware vRealize Code Stream，以及从www.vmware.com/download/eula/wavefront-terms-of-service.html下载 VMware Wavefront。

应用开发生命周期

为了理解应用转型，了解应用开发生命周期中发生的变化是很重要的。当变化的速度较慢时，应用开发总是有一个预先确定的计划，并有一个有限的目标。应用的设计是在事先经过深思熟虑并达成一致，包括捕捉所有用户的需求。然后，一系列步骤随之而来，包括制定计划、测试应用的功能、测试应用是否能够高效且正确地运行到适当的规模（非功能性测试），以及用户验收测试，以确保应用按照预期的方式构建，最终以最终格式上线。

一些现代应用的变化速度很快，加上它们在本质上可能非常实验性，这意味着瀑布式方法（在前期完全理解最终应用设计）根本不起作用。相反，应用开发、应用设计、用户甚至客户测试都在快速迭代中进行，这意味着应用是在持续的反馈循环中发展的。开发团队通常被分配到单个组件，因此没有每个人都必须遵守的受控状态的概念。开发是在同时进行的流中进行的，频繁的代码检查以确认整体功能。

我们可以将这些结果应用于 CD、DevOps 和敏捷等术语。虽然这些原则可以应用于传统应用架构，但它们最适合云基础的应用工具、平台和架构。需要注意的是，这个领域有几种模型，尽管广泛实践，但仍在不断发展。

一个非常重要的事情是要意识到敏捷和 DevOps 不是瀑布方法的替代品。客户将使用这两个学科，它们取决于应用开发需求。将敏捷开发原则应用于关键任务的传统应用可能会产生严重的后果，反之亦然，你可以使用尽可能多的云技术，但如果应用开发采用本质上是探索性的瀑布方法，将从根本上削弱有效交付的能力。

CD 管道

DevOps 通过以下程序帮助 CD 管道流程：

• 计划：我们首先需要规划和定义软件发布周期；用户定义的使用案例；敏捷计划行动；以及一个适当的待办事项和问题的跟进计划。

• 代码：这是通过一系列相关工具和流程来定义的，使我们能够编写脚本，并对其进行评估和测试。它还有助于遵循定义的安全和合规性指标。

• 提交：这可以帮助我们定义与代码评估、合并和执行相关的程序及其相关工具，并与其主源代码仓库一起执行。这个堆栈还帮助维护源控制，进行日常测试，按需执行，以及主动扫描代码。

持续集成（CI）管道

持续集成（CI）管道提供流程、实践和工具，以帮助自动化源代码仓库中每个代码提交的构建和测试。这包括自动化的安全和合规性测试以及日志记录。

自动化单元、功能、安全和合规性测试的过程、实践和工具，记录结果，并获得批准将工件提升到流程的下一阶段。

艺术品存储库由服务和活动组成，这些服务和活动对于维护与相关可交付艺术品相关的版本、提升、治理和政策控制等所需达到的预期最终状态是必要的。一般而言，这些艺术品是从源代码转换为二进制包的，尽管可能存在其他转换。

我们持续开发和更新软件，以便可以通过 CD 按需将软件发布到生产环境中。

配置由服务和活动组成，这些服务和活动对于实现自动化幂等和便捷的应用程序部署到静态和按需混合云基础设施的预期最终状态是必要的。设计和实现将与预定义的 SDLC 流程保持一致，包括适当的艺术品源代码管理（例如，Puppet 模块、Chef 食谱、部署蓝图等）。

控制栈由服务和活动组成，这些服务和活动对于管理推荐用于操作由该基础设施部署的应用程序的工具链，以实现所需的最终状态是必要的。这还将包括 SDLC 流程、工具、集成和操作，这些操作对于维护特定客户定义的服务级别协议是必需的。

反馈栈允许您在需要时获取自动反馈，例如警报、审计报告、测试报告和部署流程报告。

规划

为了实现持续成功的商业成果，VMware 与客户合作评估、推荐和记录必要的变更，以实现最佳交付流程。这项协作努力基于以下服务基础领域的行业最佳实践：

• 软件开发生命周期 (SDLC)

• 源代码管理 (SCM)

• 持续集成 (CI)

• 艺术品存储库 (AR)

• 持续交付 (CD)

• 混合云配置 (HCP)

• 配置管理 (CM)

• 持续运营管理 (COM)

SDLC

SDLC 基础由服务和活动组成，这些服务和活动对于实现人员角色、工具链和流程的最佳对齐，以实现客户期望的软件交付生命周期管理的最终状态是必要的。

SCM

SCM 基础由服务和活动组成，这些服务和活动对于在管理和版本控制软件源艺术品方面实现所需的最终状态是必要的。源艺术品包括，但不仅限于，应用程序源代码、文档、配置信息和流程控制流配置。

CI

持续集成（CI）包括实现自动化构建、测试和可交付（即二进制）工件创建所需的服务和活动。CI 流程通过使用 Jenkins、Gerrit Triggers 和 vRA 等工具，在开发者使用这些工具构建软件的同时，提供快速反馈，以辅助应用程序的构建和验证测试。

AR

VMware 和客户合作定义和细化将源代码转换为客户可交付工件的过程和活动。这包括评估和重新调整活动以及相关的关键责任角色、职责和所需技能集，关键交互和交接，这些都与支持服务定义过程有关，包括商定的用例和业务成果。

AR 基础包括实现维护版本、提升、治理和政策控制相关可交付工件所需的服务和活动。一般而言，这些工件是从源代码转换为二进制包的，尽管可能存在其他转换。

发布管道自动化（CD）

CD 包括实现自动化治理和发布政策所需的服务和活动，涉及可交付工件。这包括提供必要的工具和集成，以编排手动门控的组织决策处理和自动化交付流程。

CM

CM 基础包括实现自动化、幂等和便捷地将应用程序部署到静态和按需混合云基础设施所需的服务和活动。设计和实现将与商定的 SDLC 流程保持一致，包括适当的源工件管理（例如，Puppet 模块、Chef 食谱、部署蓝图等）。

HC

HC 基础包括实现自动化资源分配以实现应用程序部署到混合云所需的服务和活动。在此背景下，混合云可能包括以下内容：

• VMware vCloud Air、Linux 容器、AWS 和其他异构云平台

• 原地虚拟化/云和物理基础设施

此基础服务涉及提供自动化基础设施服务（即计算、网络和存储）配置所需的所有可交付工件部署的工具和集成。设计和实现将与商定的 SDLC 流程保持一致，包括适当的源工件管理（例如，配置蓝图、工作流脚本等）。

COM

COM 基础设施包括实现服务基础设施操作所需工具链以及该基础设施部署的应用程序所需的服务和活动，以实现预期的最终状态。这包括整合必要的流程、工具、集成和活动，以维护客户所承担或合理期望的任何服务级别协议（SLA）。

反馈

当发生错误时，需要对规划堆栈进行反馈。这包括错误报告和软件功能缺陷，包括操作系统及其底层基础设施所需的任何更改，所有这些都应该被跟踪以供编码堆栈处理。然后，周期继续。然后，这种反馈进入规划堆栈，我们再次开始迭代。我们始终希望确保所有堆栈都能良好地协同工作，并为我们提供预期的结果。我们的各种流程可以持续更新和改进，以跟上工具链、堆栈处理的代码类型以及结果应用程序托管的基础设施的变化和更新。

请求满足

vRealize Automation 通过统一的 IT 服务目录帮助用户请求和管理各种 IT 服务，该目录跨越混合云。

以下是为软件部署的目录截图：

它可以提供程序性访问，以支持基于 DevOps 模型的软件按需交付。

变更管理

vRO 具有内部版本控制系统，可以自动跟踪更改。它具有 API 接口，可以与 Jenkins 等第三方工具集成，并且还有一个审计日志，帮助用户审查更改和访问。vRA 可以通过集成 Active Directory 为审批流程提供自动化，还可以配置为备用审批人，以确保满足变更管理和业务需求。

发布管理

应用程序的发布流程已经发生了根本性的变化，这要求新的工具能够跟上其步伐。第一个变化是容器和微服务的兴起。它们使代码推送更快，但这是以增加复杂性为代价的。与您虚拟化环境中的 100 个指标相比，现在您需要以高速跟踪数千个指标。旧式工具无法跟上这些规模和变化，并且会失败。CD 和 DevOps 正在被大型企业采用，因此工程团队现在每天多次将代码推送到生产环境中，从而推动了持续监控的需求。DevOps 已成为主流，尽管操作团队使用的工具仍然碎片化，从而减缓了故障排除服务的速度。

合规管理

客户期望数据中心符合规范，因为这是其 IT 的延伸。公共部门、金融和医疗保健等高度监管的行业在未获得合规认证的情况下不能使用该基础设施。运行混合云或公共云基础设施的客户依赖合规认证而非独立审计来确保适当的安全控制措施到位。一系列高调的安全漏洞、法庭案件和全球立法变化提高了人们对在云中运行的复杂性和风险的意识。打开浏览器，访问marketplace.vmware.com.

VMware Cloud（VMC）在 AWS 上正在实施合规认证和框架，首先针对云安全联盟（CSA）和通用数据保护条例（GDPR），然后是国际标准化组织（ISO）、安全运营中心（SOC）、健康保险可携带性和问责法案（HIPPA）、支付卡行业（PCI）、联邦风险授权和管理工作计划（FedRAMP）和刑事司法信息服务（CJIS）。现有的安全认证适用于云计算，应予以强烈考虑。云服务将应用强制性的政策、安全、战略和合规原则，即使是最低要求的使用案例也必须遵循。

事件管理

事件本质上是指任何如果未得到妥善处理，可能导致客户升级的问题。我们可以通过实施客户事件管理流程来避免许多升级。我们在任何地理区域都没有定义客户升级流程。我们的客户关系管理方法必须演变，强调预防升级的重要性。作为回应，我们可以计划识别事件、跟踪它们并解决它们以避免升级。在此过程中，管理层监督和指导应有助于管理者在这些问题成为升级之前解决它们。沟通是主要焦点。通信协议必须定义谁、什么和何时。对客户的响应必须在获得客户满意度的成本和投资成本之间取得平衡。我们可以在升级发生之前更好地管理客户期望和问题。此流程的目的是突出那些可能早期升级的问题，以便管理层和执行层能够及时采取行动，要么防止升级发生，要么在升级发生时减轻其严重性。DevOps 团队现在作为二级支持，而在此之前，他们作为三级支持介入。

事件管理

DevOps 团队必须根据客户的要求，使用 vRealize 工具监控和管理所有应用程序，包括计算、存储、网络、虚拟机 (VMs)、容器等，并获得与应用程序相关事件的临界警报。

容量管理

自定义配置文件允许您通过根据您创建的规范自动进行容量计算来扩展容量规划的功能。选择一个已承诺的项目将改变我们的容量数字，因为它假定资源已被承诺。如果我们不希望这些数字改变，那么我们可以返回并从“容量和利用率仪表板”中选择一个计划。维护模式允许我们防止计划中的停机时间影响容量规划。

解决方案必须提供主动确定虚拟环境容量问题和风险的能力。它必须提供容量趋势、需求预测以及未来项目的假设影响分析：

将为测试和开发团队创建一个自定义仪表板。目的是在 vSphere 基础设施中提供对测试和开发虚拟机的特定视图，重点关注工作负载、剩余容量和可回收容量。以下组件将构成测试和开发仪表板：

• 开发虚拟机概述，显示服务器和工作站虚拟机的健康、风险和效率

• 虚拟机工作负载热图，以颜色编码显示所选类型的虚拟机

• 过去一周中磁盘空间容量剩余百分比最低的虚拟机：

• 空闲虚拟机和利用率最低的虚拟机，如果利用率指数变为 1，则标记为空闲

• 可回收容量显示可以回收的资源百分比

• 关闭电源的虚拟机和标记为已开启电源的虚拟机

Wavefront 仪表板

Wavefront 是一个以指标驱动的监控和分析平台。运行云原生应用的企业的 DevOps 和开发团队，如 Box、Lyft、Intuit 和 Workday，使用 Wavefront 来监控达到惊人规模的云应用性能。Wavefront 平台收集和分析在 VMware Cloud on AWS、AWS 容器、微服务、云基础设施以及甚至业务数据上运行的分布式应用的指标。一旦指标数据进入 Wavefront 时间序列数据库，Wavefront 客户就可以应用强大的灵活分析，形式为 Wavefront 查询语言。开发团队使用它以前所未有的规模监控他们的云服务和分布式应用性能。他们可以更快地解决问题，并使用即时访问和统一可见性来主动警报和检测异常的领先指标，统一可见性通过使所有云服务、基础设施和工具具有相同的可见性来加速代码发布。开发团队可以即时看到所有云服务的可见性。Wavefront 覆盖数百名工程师，实现自助服务方法，并赋予团队创新的能力，因为 Wavefront 在数字环境中提供可见性（数字服务是业务）。业务决策与应用代码交付同步，这有助于每个人在统一可见性的帮助下更快地移动。

Wavefront 提供多种数据摄取方式。我们可以直接从 AWS（APIs、CloudWatch 和 CloudTrail）检索数据，并可以从日志中创建指标。

Wavefront 与 DevOps 和开发团队的关键区别如下：

• Wavefront 允许您应用高级指标和查询驱动的分析。有超过 100 种数学变换可供您与指标数据一起使用。我们可以通过分析更快地解决问题。作为 SaaS 分析平台，Wavefront 提供大规模和高可用性。

• 它提供可定制的仪表板，帮助 DevOps 团队在生产中拥有代码的所有权。仪表板可以一键共享和导出。

• 智能警报和主动监控有助于快速检测领先指标或迅速聚焦于异常情况，我们可以通过它们期望的形状或时间，或通过我们定义的任何条件来隔离问题。

一旦 Wavefront 进入一个组织，其采用范围将扩展到数百名开发者，实现自助服务方法，并赋予他们以协作方式创新的能力。与代码发布同步的业务决策有助于 SaaS 业务加速发展。由于 Wavefront 通常在领先的 SaaS 企业中采用，并且由于他们的云服务是他们的生命线，这有助于业务领导者做出基于分析的商务决策。这些决策与云服务代码交付同步，帮助每个人更快地移动。

Wavefront 集成允许您从任何数据源收集、分析和利用数据，并将重要事项分类。Wavefront 集成通过完整的 RESTful API 和用户界面加速这一过程。来自单个工具的数据可以与其他层级相关联。Wavefront 在这些功能上具有非常高的独特性。跨层级的强大关联帮助我们赢得点工具和指标平台的胜利。Wavefront 平台提供 RESTful API 以实现可扩展性。Wavefront API 可以与开发人员或 DevOps 工具选择的任何工具集成，并使集成变得简单。例如，Lyft 希望保留他们的 Grafana 仪表板，并使用 Wavefront 作为最可扩展的后端时间序列数据库。

通过监控人们的工作方式来获得洞察

我们必须监控人们的工作方式，以便更好地了解业务和运营是否顺利进行。收集指标和监控人员总是很困难，而且我们不能强迫人们自行生成指标。因此，通过像 Slack 这样的协作解决方案以及 Wavefront 这样的 SaaS 指标监控解决方案，跟踪和监控人们的兴趣和活动变得更容易，并从中获得洞察。Wavefront 允许您应用高级指标和基于查询的分析。有超过 100 种数学变换可用于处理指标数据。我们可以使用 Wavefront 更快地解决问题，它是一个具有巨大规模和高可用性的 SaaS 分析平台。它提供可定制的仪表板，有助于 DevOps 团队对生产中的代码负责。他们的仪表板具有一键智能警报和主动监控功能，我们可以通过其期望的形状或时间，或任何已定义的条件来隔离问题。

使用 vRealize 进行自动化

vRA 可以设计成分布式和高度可用的架构，以提供多角色服务。通过将其与具有高可用性模式的 VMware Identity Manager 集成，可以在 vRA 安装向导中配置这种高度可用的架构，以实现单点登录（SSO）。它将与嵌入的 vRA 设备 PostgreSQL 内部数据库集群，因为外部 PostgreSQL 选项不再可用。它还具有集群嵌入的 vRO 服务和工作流及扩展性的高可用性。它通过访问 Microsoft Active Directory 服务器来执行用户的身份验证和 Active Directory 组成员枚举。这提供了一个规定的参考架构设计，允许 SDDC 内容生命周期解决方案。该解决方案解决了以下三个主要目标：

• 在不同环境之间自动传输 vRO 和 vRA 内容

• vRO/vRA 内容存储和版本控制，包括回滚

• 通过自动化减少测试 vRO/vRA 内容合规性所需的时间和精力

这已被设计为允许经过身份验证的用户在 vRA 环境之间同步内容。项目中定义的服务如下：

• 内容包的创建

• 在测试/验证环境中测试包

• 将包部署到部署的目标环境中

• 端点管理（添加/删除）

以下图表显示了SDDC 内容的生命周期：

以下是一些组件：

• 生产租户是生产 vRA 租户端点。vRA 和 vRO 内容部署到这个端点，以便最终用户可以消费。

• vRO 通过工作流提供捕获、测试和发布内容的编排功能。

• 工作流组织成一个 vRCS 管道，代表内容生命周期，允许内容通过开发、测试并进入生产。

• Xenon 提供内容存储功能。SDDC 内容在捕获后存储在存储库中，并在其生命周期中进行版本控制。

• 配置用于托管解决方案服务的虚拟机基于建议部署支持多达 100 个管道和多达 30 个同时管道执行的架构。

部署基础设施即代码

我们需要配置 vRA 和 NSX，这将允许从开发环境中使用隔离的虚拟机网络。

所需解决方案的网络布局如下：

NSX Edge 将提供源网络地址转换（SNAT）路由，以便隔离的虚拟机可以访问此布局中的外部开发网络资源。它还将提供目标 NAT（DNAT）端口转发，以便开发机器能够通过在此布局中指向 NSX Edge 来访问目标隔离虚拟机上的特定服务。此设计还将利用 vSphere 链接克隆技术来最小化存储需求。vRA 配置将采用以下蓝图结构：

• 基础 Windows 映像：这将提供一张空白 Windows 映像，通过 vRA 可以访问。

• 基础 Linux 映像：这将提供一张空白 Linux 映像，通过 vRA 可以访问。

• Windows 链接克隆组件：这将是基于从基础 Windows 映像和特定快照实例化的虚拟机之上的链接克隆蓝图。这代表要提供的实际隔离虚拟机。

• Linux 链接克隆组件：这将是基于从基础 Linux 映像和特定快照实例化的虚拟机之上的链接克隆蓝图。这代表要提供的实际隔离虚拟机。

• 多机蓝图：这将是一次性提供的组件蓝图集合：

为了正确提供机器，应包括以下组件：

• 外部网络配置文件：这是从外部开发网络中子网的定义，包括路由和 DNS 解析的详细信息：

• 集群预留：需要一个专门的预留来限制资源使用仅限于单个数据存储（以便链接克隆工作），以及将网络端口组映射到外部网络配置文件。

• NAT 网络配置文件：这是隔离虚拟机将在 NSX Edge 后面使用的子网的定义。这是一个将稍后复制到多机蓝图组件分配的模板：

• 预留策略：这将是一个专门的预留策略，确保所有蓝图都将仅针对创建的指定集群预留。

• 机器前缀：这仅用于区分由多机蓝图配置的机器。

vRealize Code Stream

vRealize Application Services 旨在建模应用程序并自动化其配置。vRCS 旨在建模应用程序发布过程。这两者是互补的：Code Stream 依赖于与虚拟现实即服务（vRAAS）、脚本、Puppet 等的集成来部署代码。Code Stream 允许我们将整个发布过程和构建在不同阶段和/或环境（功能测试、负载测试、系统集成测试、预发布和最终生产）中的推广过程进行编码或建模。这包括不仅通过脚本或其他工具触发应用程序部署，而且在决定将构建推广到下一阶段之前触发测试并查看测试结果。

它还支持在阶段中创建手动任务，用于处理目前尚未自动化的操作。这实际上是一个流程编排工具，而不是应用部署或配置解决方案。Code Stream 允许我们触发单个工件（.jar、.war、配置文件等）的部署，而与 vRAAS 不同，后者迫使我们重新部署整个堆栈，包括底层机器。一个 Code Stream 设备可以处理大约 100 个并发管道执行。Puppet、Chef 和其他配置管理工具不是 Code Stream 的直接竞争对手。这些工具通常用于配置和部署软件，但 Code Stream 完全是关于建模发布过程。Code Stream 的核心价值实际上是将配置管理、基础设施配置以及持续集成和测试与审批系统结合起来，以自动化整个发布过程。

这有几个技术优势：

• Code Stream 可以自动化和加速任何类型软件的生命周期。这包括应用程序（传统和云原生）、以及基础设施和 IT 内容（蓝图、工作流、脚本、模板等）。

• 代码流不指定特定的发布模型或工具集。它可以模拟刚开始的公司发布过程，并将大部分手动任务转换为 100%自动化的发布模型。因此，它适应组织的成熟度水平，并允许他们逐步向更自动化的模型过渡。

• 代码流允许团队将代码提供和部署到私有云以及公共云。代码流可以利用 vRA 的集成蓝图或与其他提供解决方案（如 Cloud Foundry）一起工作。

• VMware 从基础 SDDC 到管理/提供层 vRA，再到代码流提供的发布自动化功能，提供最佳的全栈和完全集成解决方案。因此，虽然所有产品都可以独立使用（无供应商锁定），但当它们一起使用时，客户将拥有一个无与伦比的平台，帮助他们变得更加敏捷。

我们可以在没有 vRA 的情况下安装代码流，因为将两个产品部署在一起以获得自动化提供和发布自动化完全集成解决方案的好处是肯定存在的。代码流支持两种部署模式：

• 独立模式，在虚拟设备上仅启用代码流功能。管理员可以选择配置代码流，通过外部 vRA 设备提供机器。

• 统一模式，在同一个设备上同时启用代码流和 vRA 功能。vRA 还需要一个单独的 Windows 服务器来提供 IaaS 功能。此配置不是生产支持的配置。

Jenkins 是一个构建自动化工具，它促进了持续集成（CI），这是一种开发实践，要求开发者每天将代码集成到共享源代码库（如 Git）中几次。每次提交都会通过自动构建进行验证，使团队能够及早发现问题。任何 CI 工具的核心都是一个自动化构建和与构建相关的活动（如预构建或后构建运行的测试）的作业。

发布自动化工具，如代码流，专注于模拟和自动化更广泛的发布过程，直至生产，这通常包括持续集成（CI）以及提供、变更管理和监控等其他工具类别，并且通常，人们为此进行一些手动任务和/或审批。公司通常使用发布自动化工具来努力实现持续交付（CD），这是一种每次良好的构建都可能推送到生产的实践。CD 是 CI 的超集，涉及更多工具和更多团队——不仅仅是开发团队，还包括运维和发布团队。发布自动化或 CD 工具的核心是管道，它模拟一个过程，包括诸如审批等业务结构。

Jenkins 是一个可扩展的工具，可以定制以超越基本的构建和测试，以编排发布过程中的其他活动。我们可以定制 vRO 工作流来完成 vRA 的一些功能，但最终我们可能会编写大量的逻辑，使得基于工作流解决方案的维护变得困难。同样，在 Jenkins 之上的定制解决方案也可能出现这种情况：它们可能最初工作良好，但随着时间的推移管理起来越来越困难，尤其是在尝试管理更多应用程序时。这就是构建与购买方法典型的缺点。Jenkins Enterprise 具有管道组件以实现发布自动化。它仍然缺乏一些关键功能，如手动任务和审批以及管道中步骤之间轻松传递变量，这些通常是顶级发布自动化供应商提供的。

由于以下原因，Code Stream 仅作为独立产品提供：

• 它不符合 vCloud 或 vRealize 等套件的所有要求和预期功能。例如，它不支持本地化、高可用性或无人值守安装。

• 它需要快速演进，并比现有套件遵循更频繁的发布节奏。

• 它与 vRA 共享一些常见服务，但可以在不使用 vRA 的情况下部署，这样不使用 vRA 的发布工程师或 DevOps 团队仍然可以拥有一个轻量级的持续交付解决方案。

管道自动化模型 – 任何类型软件的发布流程

vRealize Code Stream 被希望自动化其发布或持续交付（CD）流程的客户所使用。vRealize Code Stream 通过降低运营风险，允许开发者和运维团队能够更频繁地发布软件。它基于集成和扩展而非完全替换的原则设计，这样我们就可以在软件开发生命周期（SDLC）中使用现有工具。这将帮助开发者利用他们在工具和技能上的现有投资。在撰写本书时，vRealize Code Stream 有三个主要功能：

• 管道自动化

• 艺术品管理

• 发布仪表板

它将提供基于全面集成框架的 RESTful API 和功能。以下是一些手动任务的示例：

• 审批流程：Code Stream 拥有自己本地的审批流程能力，该能力与其他 vRealize 产品共享。审批流程可以在管道执行过程中的任何阶段添加人工监督。此外，Code Stream 还可以利用 vRO 插件调用工单票务系统来协调审批流程。

• 建模手动任务：需要手动执行的任务通常需要通过工单票务系统向任务所有者发送某种类型的通知。Code Stream 利用 vRO 工作流和插件与现有的系统（如 BMC Remedy IT 服务管理（ITSM）、HP 服务管理器、ServiceNow 等）集成。

vRCS 部署架构

本章描述了 vRCS 推荐的部署拓扑。vRCS 可以利用 vRA 进行 VM 配置。有几种可能的部署方式：

• vRCS 和 vRA 在同一单个设备上（推荐用于小型 POC，其中 vRCS 和 vRA 都是实验室/评估系统）

• vRCS 和 vRA 部署在两个独立的设备上（推荐用于大型 POC 或生产环境）

• vRA 在两个独立的设备上部署且启用 HA（推荐用于大型 POC 或生产环境）

• 作为外部实体部署的 Artifactory

vRCS 不支持连接到外部 vRO，也不支持其自己的 HA 设置，但它可以与外部 vRA 的 HA 设置集成以进行 VM 配置：

• vRCS 和 vRA（vRA）在同一单个设备上

• vRCS 和 vRA 在两个独立的设备上

• vRA 在两个独立的设备上部署且启用 HA（推荐用于大型 POC 或生产环境）

• 作为外部实体部署的 Artifactory

在配置部署时请注意以下事项：

• 如果 vRCS 和 vRA 的部署在同一设备上，可能会锁定整个设备。由于 vRA 的 HA 设置有自己的 SSO 服务器，并且没有身份联合支持，vRCS 必须使用共享用户账户来访问 vRA。

• 请将 vRA 端点配置为共享账户，而不是每个用户会话。vRCS 与高级服务设计器（ASD）表单集成，vRCS 1.2 附带了一个名为 ASD 的新插件。此插件仅适用于内部 vRA。

系统架构

vRCS 架构描述了与系统架构相关的各种组件。vRCS 和 vRA 可以在同一设备上运行，前提是拥有适当的许可证。vRCS 需要配置端点，以便它可以与任何外部产品或服务部署集成。即使 vRA 和 vRCS 在同一设备上，vRCS 也需要从 vRA 获取端点，以便与 vRA 进行 VM 配置通信。

vRCS 可以通过两种方式与 vRA 交互：

• 共享账户（使用单个共同用户）

• 每个用户会话（SSO）：

用户可以访问以下端口：

服务器角色	端口
vRCS/vRA 设备	443
vRA 身份设备	7444

下图表示了 vRCS 通信工作流程：

除了用户所需的端口外，管理员还需要访问以下端口：

服务器角色	端口
vRA 身份设备	5480
vRCS/vRA 设备	5480
服务器角色	入站端口
vRCS/vRA 设备	443SSH: 22VAMI: 5480
vRA 身份设备	7444SSH: 22VAMI: 5480

将 vRCS 与外部独立 vRA 集成

vRCS 可以与现有的 vRA 集成以进行虚拟机配置。因此，需要创建一个端点，以便可以指定与外部 vRA 端点相关的详细信息。此端点将在添加阶段任务时列在配置类别下。此端点可以支持共享账户和每个用户会话选项。如果外部 vRA 和 vRCS 链接到同一个 SSO 服务器，则每个用户会话和共享账户选项都受支持。然而，如果外部 vRA 有自己的 SSO 服务器，则仅支持共享账户选项。这是因为两个 SSO 服务器之间的身份联合不支持。

用户需要访问以下端口：

服务器角色	端口
vRCS	443
vRA 设备	443
vRA 身份设备（Code Stream）	7444

除了用户所需的端口外，管理员还需要访问以下端口：

服务器角色	端口
vRCS	5480
vRA 设备	5480
服务器角色	入站端口
vRCS	443SSH: 22VAMI: 5480
vRA 设备	443SSH: 22VAMI: 5480
vRA 身份设备（Code Stream）	7444SSH: 22VAMI: 5480

摘要

Code Stream 提供了对任何类型软件（应用程序、蓝图、工作流、配置文件、Puppet 规范、Chef 配方等）发布过程的建模和可视化的能力。所有利益相关者（开发者、运维团队、发布工程师等）都可以前往一个中心位置跟踪应用程序和软件发布的状态。用户不仅可以查看历史记录，还可以确切地看到构建和发布失败的确切位置。Code Stream 和 vRA 使用相同的交付平台（相同的虚拟设备）并共享许多共同的服务，包括捕获 IT 在努力解决或花费大量时间解决的问题，并通过 vRCS 和 vRA 自动化这些问题。

与获取、集成和管理不同解决方案以实现供应和发布自动化相比，客户可以受益于单一解决方案。通过集成到如 JFrog Artifactory 这样的工件存储库，Code Stream 可以管理和跟踪由新版本生成的大量工件版本，并跟踪它们在各种环境中的部署。随着公司更频繁地发布新应用程序版本，部署错误工件版本并破坏生产的风险显著增加。为了帮助客户对其所有不同的存储库（如 Yum、NuGet、Nexus 等）有可见性并将它们整合到一个地方进行故障排除和安全审计，跟踪哪些工件部署在哪里非常重要。Code Stream 可以为 Java/Linux 和.NET/Windows 商店及其相应的工具集工作。某些发布管理工具（例如，Octopus、Microsoft Release Manager 和 Chef Delivery）仅支持一种技术或针对一种技术或某些工具集进行优化。Code Stream 不指定任何特定的工具集，这意味着它可以支持企业中使用不同技术的不同团队。实际上，它甚至可以用于非应用程序软件的生命周期：脚本、工作流、蓝图等。

在下一章，第十章，使用机器学*改造 VMware IT 运营中，我们将了解如何从单个控制台管理不同的云模型以及数据中心运营方法的阶段性转型。我们还将了解如何使用基于机器学*的解决方案设计可扩展的基础设施，以在统一平台上托管旧的和新的云原生应用程序。

进一步阅读

• DevOps 和敏捷开发—VMware，请访问 www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/solutionoverview/vmware-devops-agile-development-white-paper.pdf

• vRealize Code Stream Management Pack for IT DevOps—VMware，请访问 www.vmware.com/files/pdf/products/vrealize/vmware-vrealize-code-stream-management-solution-brief.pdf

• DevOps-Ready IT：vRealize Automation Blueprints 的持续交付，请访问 blogs.vmware.com/management/2016/05/devops-ready-it-continuous-delivery-of-vrealize-automation-blueprints.html

• vRealize Code Stream | 应用程序发布自动化，请访问 www.vmware.com/in/products/vrealize-code-stream.html

• vRealize Code Stream 文档——VMware Docs，在docs.vmware.com/en/vRealize-Code-Stream/index.html

• 使用云自动化从零到 DevOps 英雄，在blogs.vmware.com/management/2018/10/devops-hero-with-cloud-automation.html

• vRealize Code Stream——VMware，在code.vmware.com/web/sdk/2.2.0/vrealize-code-stream

• vSphere 集成容器概述——针对 DevOps 管理员——VMware vSphere，在vmware.github.io/vic-product/assets/files/html/1.1/vic_dev_ops/overview_of_vic_devops.html

第十章：使用机器学*转型 VMware IT 运营

本章将帮助您了解 VMware 云自动化运营转型如何创建和实施生命周期方法来管理和交付基于 SDDC 的服务，以帮助客户过渡到服务提供商组织。这项服务侧重于优化组织和流程能力，以支持软件定义数据中心（SDDC）概念，实现这些以模块化格式提供的技术全部功能，并通过技术、人员和流程的集成来提供真正的商业效益。

这种基于服务的方法针对的是既有 VMware 基础设施经验的新客户和现有客户，但他们可能没有云自动化解决方案中产品的经验，或者没有基于 SDDC（软件定义数据中心）提供服务的经验。云自动化服务的运营转型通常是大型项目中的一个关键步骤。

在本章中，我们将学*如何从单个控制台管理云模型，并通过设计可扩展的基础设施在不同阶段转型数据中心运营，以运行遗留和新的云原生应用。我们将利用 SDDC 方法中的机器学*技术来完成这项工作。

在本章中，我们将涵盖以下主题：

• 商业和运营挑战概述

• 转型 VMware 技术支持运营

• 虚拟数据中心

商业和运营挑战概述

我们正试图推动应用管理转型，通过 VMware 解决方案使生活更轻松。我们可能会遇到管理应用时出现的一些问题，例如遗留的配置、复杂且耗时的更新，以及必须管理用于应用交付的单独解决方案。VMware 在管理应用方面采取了不同的方法。我们有方法可以将一个应用部署到多个桌面，从而节省大量时间和存储成本。我们可以在几秒钟内以规模交付应用。我们可以隔离应用以消除应用冲突的障碍。应用可以在任何设备和一个门户上使用。我们甚至可以改变您监控应用程序以获得更好性能的方式。

VMware 云操作和利益相关者希望分析本地私有云基础设施服务的消耗情况，与他们的客户不同功能组相关联，以确定当前趋势、未来需求和预算合规性。客户的云操作和利益相关者必须向客户收取所消耗的资源费用。客户的利益相关者希望获得一个精确的成本视图，这些成本是提供单位 IaaS 资源所需的，更好地了解其组成部分的负载成本，并提供运行 IaaS 的总拥有成本（TCO）。客户获得运行 IaaS 基础设施的总资本支出和运营支出，因此他们希望将这些成本分配到构成服务的底层资源上。这些资源包括 CPU、RAM、存储、操作系统、许可证和人力。客户的私有云操作团队、云管理员和指定的业务所有者必须通过深入了解云基础设施如何分配给业务单元，以及分配和未分配资源的成本，如 CPU、RAM 和存储的成本，来实现基于成本的分析和决策。他们希望按资源类型分析分配和未分配的基础设施成本。云管理员还希望确定现有基础设施上是否有可用于运行虚拟机的硬件，为即将到期或结束支持的旧服务器组创建报告，并创建自动报告以向利益相关者展示可能需要采购的新基础设施。

云操作和业务所有者希望分析本地私有云基础设施服务的消耗情况，与客户的业务功能组相关联，以确定当前趋势、未来需求和预算合规性。云操作团队希望向客户收取所消耗的资源费用。他们希望使用 vRA 软件向消费者提供私有云服务。私有云资源托管在客户的数据中心，这就是为什么业务利益相关者要求制定最佳定价策略，以衡量私有云资源的商业价值，即投资回报率。

一个 IT 开发和运营团队需要快速提供新的应用程序及其几乎每年都要进行的持续更新。这些应用程序包括 Oracle 企业资源规划等完全功能的应用程序，以及与各种 SaaS 应用程序集成的本地应用程序，如 My VMware 门户。新软件实例的修改和测试速度慢，且大多因人工流程而容易出错。开发团队在项目期间通常需要一个应用程序开发实例和一个应用程序测试实例，为期几周。即使在应用程序部署后，他们还需要额外一周的时间进行纠正，才能将应用程序投入生产。这将使业务等待新应用程序。

云管理员对客户负责特定服务的定义、设计、部署、持续维护和支持，并与架构师和开发者合作，最大限度地提高自动化水平以支持服务并管理其性能。他还要对服务的服务管理交付负责。

没有服务所有者对运营团队带来的挑战

我们缺乏一个单一的客户联系点，这为客户联系 IT 创造了不同的、个体的渠道，可能会影响客户体验。它也无法提供服务的整体、端到端愿景，导致客户对服务的理解不足，以及对客户需求的调整。这种方式，所有权在不同人之间分散，可能导致服务生命周期阶段或不同利益相关者之间的断裂，或者让不同人之间出现重复。它还由于缺乏单一的责任点而倾向于指责，最终导致缺乏明确承诺发展服务并更广泛地推广云的被动管理。它还将缺乏整体愿景，因为相同的服务可能在企业内以不同的方式提供，使得标准化更难转向服务的主动管理。

具有服务所有者的解决方案

一旦服务所有者被提名，我们就会拥有清晰的所有权，并有一个单一的责任点。它将通过在 IT 和客户之间促进责任，确保持续交付和服务的持续改进，从而转变为组织内服务一致交付的持续方法，这样他们就可以专注于服务的端到端质量，其与客户需求和 IT 战略的一致性，以及其未来的演变。它还将推动服务的主动管理和优化。

服务所有者的职责

服务所有者负责整体服务定义和以下云服务提供的交付：

• 在客户的新服务需求下，召集所有必要的 IT 利益相关者来定义服务范围、目标、SLA 等

• 管理开发和增强工作，并与云服务架构师合作

• 通过对服务的整体愿景，改进服务以及扩大需求

• 持续监控并报告其云服务产品在服务级别上的达成情况

• 定义 KPI 和报告，这对于管理实时服务是必要的

• 与客户保持活跃的对话，以预测并采取必要的行动来关注服务性能

• 负责服务台培训，根据对服务和客户目标的理解，将新服务或变更的服务投入生产

• 与支持团队紧密合作，定义最佳流程，并确保支持团队能够得到支持

• 对管理服务门户信息、参数和特性负责

• 确保客户在门户中拥有正确的信息，并在新服务或服务变更的情况下能够理解他们所接受的服务

• 协助云服务产品的服务成本和财务模型，对于服务成本负责

• 与包括财务和客户在内的适当利益相关者建立正确的成本模型，并教育客户如何驱动客户的消费行为

转型 VMware 技术支持运营

VMware 正在 Workspace One 中创新智能功能，以获取客户洞察并增强安全性。通过使用机器学*，身份管理将监控用户行为、软件性能和硬件信息。商业应用将带有 AI 功能。VMware Skyline 将帮助节省时间，因为收集产品数据、事件和条件以及识别问题将更快，从而实现更快的问题解决时间（TTR）。最初影响最大的领域将是围绕问题识别，以及支持工程师找到报告问题的答案所需的时间，同时发送用于支持调查的产品数据。VMware Skyline 将确保遵循VMware Validated Designs（VVDs）。所有与高级支持服务团队相关的支持工程师将负责理解 VMware Skyline 的价值和好处，并将其纳入日常对话中，通过鼓励客户下载和安装收集器来推动客户采用。随着查看器的可用，支持工程师在工作处理 VMware Skyline 客户的支持请求时也需要积极使用它。支持账户工程师（SAEs）和支持账户经理（SAMs）可以使用运营摘要报告（OSR）进行更具影响力的对话，增强并拓宽这些通话的焦点，使其更具前瞻性。它将帮助总结已识别的变化以及修复已识别任何潜在问题的建议。将汇编与客户审查相关的相关知识库（KB）文章、现场警报和安全问题。

客户成功仪表板将使用 VMware Skyline 数据来突出客户从 VMware 产品和服务的最大价值实现机会。客户成功团队成员将负责理解 VMware Skyline 的价值和好处，并将其纳入日常对话中，以推动客户采用。客户成功团队可以利用 VMware Skyline 数据，因为它将提供产品使用数据，这将作为客户健康评分的关键输入。它将提供购买与部署数据（应用采用）以及通过客户健康检查报告提供健康信息，该报告可供服务团队使用。这份报告目前应每季度运行一次。

Skyline 还将提供有关产品版本的关键信息，以确保在升级之前产品的兼容性。它还将提供硬件信息，以显示与 VMware 产品的当前状态兼容性，以及一个站点配置文件，它将为 VMware 产品提供客户环境的拓扑视图。这是一个允许顾问与客户互动并提供建议的工具，以便实施团队能够继续推动所有执行计划和这些建议的实施。

实施团队能够查看客户发送回的 VMware Analytics Cloud 中的传入数据，但服务团队必须在请求以原始格式访问数据之前完成数据隐私培训。VMware Skyline 对客户来说应该是无缝的，并且没有额外的成本，因为它包含在他们的支持订阅中。在 VMware Skyline 上的客户将能够更快地解决反应性支持案例，从而更快地回到业务中。通过主动、预测和指导性建议，可以更快地解决反应性支持问题，这将提高环境的整体性能和健康。整体环境健康将包括改进的可靠性、可伸缩性、配置、设计合规性和跨产品建议。

许多客户依赖与 VMware 授权服务提供商的合作关系来管理和支持他们的 VMware 部署，因此合作伙伴应纳入 VMware Skyline 计划，以利用这项技术在联合支持过程中。vSAN 支持分析构建可伸缩的支持机制，以利用 CEIP 框架。收集到的各种数据允许健康检查团队快速测试现有健康检查的改进以及新的健康检查的准确性。vSAN 兼容性指南团队确定问题的常见原因，而工程团队修复尚未报告或升级的问题。

支持团队可以通过缩短整体解决时间和提升客户支持体验来快速解决问题。产品管理团队能够通过更好地理解客户如何配置他们的环境来更好地优先考虑功能，而产品开发团队则需要优先考虑额外的配置辅助功能，以修复最常见的配置问题。这将为生产支持客户所利用，并用于反应性支持目的。vSAN CEIP 数据通过 SSL（HTTPS）协议从 vCenter Server 传输。这将利用为 vCenter Server 配置的代理。CEIP 数据传输到https://vcsa.vmware.com。由于独特信息复杂，vSAN 目前正使用 CEIP 数据进行配置、健康和性能遥测。

SDDC 服务

通过一系列模块化服务组件实现 SDDC，这些组件逐步构建组织能力以定义、设计、开发和发布云服务，并通过它们发布的目录来管理服务。这些模块化服务可以单独交付，也可以作为一系列按顺序构建的模块，这些模块逐渐建立在彼此的结果之上。这些组件从需求识别开始，然后开发可重复的过程，并通过对这些过程与用例的验证来实施。

服务目录管理

此服务通过设计、管理和运营客户云服务目录以满足可用性、服务发布和自助服务业务需求，从而提高了发布云服务对用户和商业自助服务的可预测性。它还提供了将已同意的服务用例发布到云服务目录，以验证正确的操作流程，支持以服务/租户为中心的角色、责任和技能集启用指南，使客户能够管理和交付服务目录的能力。

服务设计、开发和发布

这通过将客户云服务的设计、开发和发布过程应用于云基础设施，提高了构建和发布云服务的运营能力。通过实例化已同意的服务用例来验证和细化服务设计、开发和发布过程。该流程是为基于冲刺的敏捷服务开发设计的，但通过假设单一的开发周期，该流程仍可用于传统的瀑布式服务开发方法。

云业务管理操作

通过详细报告，云业务管理服务可以启用以实现更好的 TCO 和 ROI，并快速做出业务决策，帮助云服务所有者找出整体端到端特定云服务每单位成本，包括以下内容：

• 云服务成本

• 定价

• 反映报告

服务定义和自动化

这是一种通过使用经过验证的方法来发现、评估和开发服务自动化路线图，从而全面定义客户云服务自动化和配置路线图的方法。此服务为客户提供了清晰且可操作的路由图，以在他们的云环境中实施自动化配置和部署能力。它提供了一个服务定义框架、流程和一系列可重用模板，以实现客户对已同意服务用例的全面定义，并提供以服务/租户为中心的角色。

NSX for vSphere

我们首先需要了解当前的部署情况和未来的期望，以及所有与在不同地区托管在公共云中的应用程序（包括订阅详情）相关的信息。我们应该收集有关虚拟网络/虚拟私有云（VPCs）的信息，包括每个 VPC/VNET 中生成的所有虚拟机。我们必须设计一个网络，使用 NSX 为 PaaS 服务（如 API 管理器）提供支持，以及本地环境，并且不能将本地环境与公共云环境分开管理。我们必须建议在两种环境中托管应用程序、数据库和 Web UI，并通过专用的高速路由/直接连接连接连接到公共云。

虚拟云网络（VCN）是数字时代的网络模型。它也是 VMware 对网络未来的愿景，使客户能够从边缘到边缘连接和保护应用程序和数据，无论它们位于何处。它允许客户采用云网络布线作为连接分布式世界中一切事物的软件定义架构。它是一个无处不在的软件层，为用户提供用户、应用程序和数据之间交互的最大可见性和上下文。虚拟云网络是下一代网络服务消费技术的类别，正在被越来越多地采用于 IT，以提供帮助统一超分布式世界的数字布线。

ESXi 主机为 vSphere 上的 NSX 准备，以下值：

最大传输单元（MTU）	9000
段 ID	5000–7999
团队模式	源 MAC 地址
传输区域	1—包括所有集群

NSX 正在从数据中心扩展到边缘，因为实现 VCN 需要一个相当强大的产品组合。NSX 数据中心是数据中心网络的最佳端到端一致平台。NSX 云正在将数据中心网络扩展到公共云，包括 AWS 上的 VMC、本地的 Azure 支持以及与Pivotal Container Service（PKS）的容器/Kubernetes 支持。我们打算提供控制、策略和自动化，这些控制、策略和自动化位于数据中心，以保持一致性，将它们提供给客户正在运行的云环境。

NSX 混合连接将有助于提供应用程序和网络混合性和移动性。通过vRealize Network Insight（vRNI）提供的强大网络洞察和发现将推动物理、虚拟和云环境中的安全性和网络优化。以下图示了一个基于传统 VMware vSphere 的基础设施和一个基于VMware Cloud Foundation（VCF）（HCI/VSAN）的虚拟基础设施，两者都集成了NFS 存储：

SDDC 分层方法

如果我们在本地使用 NSX，我们可以使用交换机端口分析仪、IP 流信息导出（IPFIX）等本地功能。在这里，我们可以使用 Traceflow 来窥视数据包的流动情况。一旦我们开始迁移到云端，这就会变得复杂。这是因为有一个底层网络，它不由客户运营。骨干网络属于 AWS 或 Azure，因此我们希望从这样的工具中获得的是跨所有云账户和用户的端到端、实时操作可见性。

每个公共云提供商都有创建和实例化安全组的不同方式，管理所有这些可能会变得困难。客户现在运营云，因为每个团队都会创建自己的 VNET，并且在该 VNET 的安全策略在部署前会手动讨论。每当需要运行新事物时，都会提出一个工单。他们通常会创建安全组，并将这些安全组附加到本地环境中的虚拟机上。

每当创建一个新的虚拟机时，该虚拟机会继承与它关联的安全组所基于的一组限制。在下面的图中，我们可以看到如何配置了一个基于 VSAN 的四节点集群，并使用分布式交换机来托管所有管理虚拟机，例如SDDC 管理器、vCenter、NSX 管理器、vRealize Log Insight设备、PSC 控制器和 NSX 控制器：

工作负载集群

vRA 简化了应用程序部署流程，该流程消耗网络并包含定义蓝图，这允许自动部署新网络。NSX 是网络的未来，我们准备好帮助客户在数字化转型中前进。我们有一种强大的技术，我们相信在数字时代网络将如何发展。VMware 正在解决关于多云、多应用框架和现代应用程序构建的关键客户需求，并使一致的网络和安全策略能够跟随应用程序和数据在整个 IT 环境中。NSX 是网络的未来，我们很兴奋能帮助我们的客户在数字化转型中前进。vCenter 服务器和 Active Directory 服务器被添加到排除列表中，以避免任何人为错误，并且始终可用。为该环境创建了以下安全组、策略和规则。

优先级建议

ESXi 主机的物理配置规范列出了 ESXi 主机的特性，可以在部署和测试期间按照 VMware 最佳实践使用。每个系统的配置和组装过程是标准化的，所有组件在每个 ESXi 主机上以相同的方式安装。标准化 ESXi 主机的整个物理配置对于提供易于管理和支持的基础设施至关重要，因为标准化消除了可变性。您可以在所有集群成员中部署具有相同配置的 ESXi 主机，包括相同的存储和网络配置。例如，一致的 PCI 卡插槽位置，特别是对于网络控制器，对于物理到虚拟 I/O 资源的准确对齐至关重要。相同的配置确保了虚拟机存储组件在存储和计算资源之间的平衡。以下是我们提到的建议及其优先级。

优先级为 1 的建议

以下约束属于优先级为 1 的建议：

• 在所有集群上启用 HA 准入控制。原因：始终保护运行中的工作负载。

• 在某些集群中增加主机数量以分析各种场景。原因：在某些集群中，由于硬件故障，可能没有足够的 ESXi 主机来运行所有现有的虚拟机。

• 使用资源池，既为站点恢复管理器（SRM）故障转移的虚拟机保留资源，又确保在争用事件期间公平访问资源。原因：保护工作负载。

• 从集群中的虚拟机中移除 CPU 预留。原因：在 ESXi 主机故障的情况下，虚拟机重启可能会失败。配置没有提供任何真正的益处。

• 确保所有 ESXi 主机上的网络时间协议（NTP）配置正确，并且 NTP 服务器已启动。原因：在任何 IT 环境中，准确的时间维护都是必不可少的。

• 使用基于物理 NIC 负载均衡算法的路由进行虚拟机网络。原因：最大限度地利用可用的网络带宽，保护工作负载。

• 调查 vSphere 5.1 加固指南中的所有 3 级建议。除非有特定原因不应用安全建议，否则应应用所有建议。原因：提高安全性。

• 对于具有 RDM 的特定虚拟机案例，将虚拟机配置文件和.vmdk文件放置在其自己的数据存储上，并创建包含数据存储和 RDMs 的 SRM 保护组。原因：确保这些特定虚拟机可以成功且独立于其他虚拟机恢复。

• 深入了解虚拟机的恢复优先级和依赖关系，并适当配置 SRM。原因：增加信心，以便在灾难恢复事件中，虚拟机可以正确且在预期时间内恢复。服务通常有首选的启动顺序，在灾难恢复故障转移期间也应遵守。

• 在 SRM 中，根据需要配置 1:1 的数据存储到保护组映射。原因：这消除了向 ESXi 主机添加新 LUN 时出现的问题，以及在一致性组重新同步期间可能无法进行灾难恢复的情况。它将允许同时启动多个恢复组，并允许测试或故障转移特定服务，而不是每个受保护的虚拟机。这增加了复杂性，但为灾难恢复计划引入了大量智能和意识。

• 在灾难恢复事件中，预先确定 50%的银色虚拟机的恢复列表。原因：在灾难恢复事件中消除混淆，并允许在受控条件下测试灾难恢复计划。

• 在恢复计划中引入基于服务的方法，以便根据需要测试和恢复单个服务。原因：这为灾难恢复带来了面向服务的方法，并允许测试或故障转移特定服务，而不是每个受保护的虚拟机。这增加了复杂性，但为灾难恢复计划引入了大量智能和意识。

• 定期进行测试恢复，以增加对灾难恢复按预期运行的信心。原因：增加信心，以便在灾难恢复事件中，虚拟机可以正确且在预期时间内恢复。

• 使用最佳实践推荐配置所有虚拟化 Microsoft SQL Server 集群。原因：确保集群的稳定性并移除影响性能的配置。

优先级为 2 的推荐

以下限制属于优先级为 2 的推荐：

• CPU 利用率通常较低，因此考虑增加每个 ESXi 主机的 RAM 量。原因：这会导致更高的整合比率，而不会影响 CPU 性能。

• 确定是否需要严格执行 1vCPU: 4 GB RAM RU 模型。原因：可能造成计算资源的浪费。可能导致更高的整合比率。

• 不要让完全备份作业与防病毒扫描重叠，以限制对 ESXi 主机 CPU 利用率的冲击。原因：减少 ESXi 主机的 CPU 负载需求，否则可能会导致虚拟机和服务性能下降。

• 将虚拟机的防病毒扫描分散到多个时间窗口，以限制对 ESXi 主机 CPU 利用率的冲击。原因：减少 ESXi 主机的 CPU 负载需求，否则可能导致虚拟机和它们上运行的服务性能下降。

• 为每个 vCenter 服务器配置 DRS 规则。原因：始终保护 vCenter 服务器虚拟机。

• 为每个 vCenter 服务器配置内存预留。原因：始终保护 vCenter 服务器虚拟机。

• 将每个 vCenter 服务器的 HA 重启优先级配置为高。原因：始终保护 vCenter 服务器虚拟机。

• 识别并配置所有 ESXi 主机的辅助 NTP 服务器。原因：当前实现中存在单点故障。准确的时间记录是任何 vSphere 实现的重要组成部分。

• 调查使用主机配置文件或 PowerShell 脚本来检查和修复 ESXi 主机配置差异的使用情况。一旦确定了解决方案，就进行定期检查以确保 ESXi 主机配置的一致性。原因：这确保了所有 ESXi 主机具有标准构建和配置，从而简化了故障排除。

• 自动化故障转移虚拟机的资源池预留，并自动化资源池共享，以确保在争用时公平共享集群资源。原因：保护工作负载。

• 修改 vCenter 服务器设置，以便任务和事件在 180 天后（或任务和事件需要在虚拟应用设备中保留多长时间）被截断。原因：这可以防止 SQL Server 数据库变得过大，这可能导致性能问题。

• 使用vSphere 分布式交换机（VDS）进行所有 ESXi 主机的网络配置。原因：它更容易配置，并且更简单。为所有 ESXi 主机提供更一致的网络安全配置。

• 修改 HP 虚拟连接环境中虚拟网络接口卡（vNICs）的网络带宽配置，以最大化网络带宽的整体使用。原因：更有效地使用所有可用的网络带宽。

• 配置多 NIC vMotion。原因：通过更有效地利用网络带宽，这可以加快 vMotion 事件。

• 识别所有需要为授权目的指定特定 MAC 地址的虚拟机。将此 MAC 地址硬编码到虚拟机配置中。修改所有分布式端口组，使伪造传输和 MAC 地址更改设置为拒绝。原因：这提高了 vSphere 环境中的安全性。

• 配置 SSO 管理员组，并将适当的 Active Directory 账户添加到其中。原因：提高了安全性和可审计性。

• 从 vCenter 服务器中的admin@system域账户中移除权限。原因：提高了安全性和可审计性。

• 在 SSO 中修改密码过期超时以满足本地安全策略。原因：提高了安全性。

• 将所有 ESXi 主机添加到 Active Directory 中。使用ESX Admins组（或创建自己的组并适当配置）并填充 Active Directory 用户账户。配置适当的 SSH 和 ESXi shell 超时。修改所有 ESXi 主机的 root 密码，使其长且复杂。将密码存储在安全位置。培训员工使用 Active Directory 账户连接到 ESXi 主机，而不是 root 账户。原因：提高安全性和可审计性。

• 创建数据存储集群并添加适当的数据存储。以手动模式配置存储 DRS 设置，禁用 I/O 测量。原因：使虚拟机的放置任务变得不那么复杂。

• 在所有数据存储上启用存储 I/O 控制，并对所有虚拟机和运行在其上的工作负载进行全面分析。为托管应用程序配置虚拟机的特定最佳实践。原因：保护工作负载。

• 确保所有虚拟机都安装并运行了最新的 VMware 工具。原因：提高性能、安全性、兼容性和可管理性。

• 识别所有配置了超过 4GB RAM 且运行的操作系统不支持超过 4GB 使用的虚拟机。原因：减少计算资源浪费。允许有更高的整合比率。

• 升级到更*版本的 vSphere。原因：利用新软件功能，提高性能水平，并包括对更新硬件的支持。

• 升级到vRealize Operations Manager（vROP）6.7。原因：利用显著改进的架构。

• 识别并实施 vROP 仪表板的用例。原因：利用 vROP 中可用的大量指标，提供对 vSphere 平台的深入可见性，并以易于消费的方式可视化。

• 识别如何将 vRealize Operations Manage 集成到整体监控解决方案中。原因：提高对 vSphere 环境的监控。消除使用 vCenter Server 警报的需要，这些警报在功能上不如 vROP。

优先级为 3 的建议

以下约束属于优先级为 3 的建议：

• 只在绝对必要时使用具有大量 vCPUs 的虚拟机。原因：减少整合比率，当虚拟机超过非一致性内存访问（NUMA）边界时增加复杂性，并可能影响性能。

• 使用 HA 重启优先级在物理主机故障时首先将重要的虚拟机恢复在线。原因：通常首选智能重启虚拟机。

• 改变主机容量计算的方式。原因：现有方法复杂且易出错，可以通过 vROP 自动化并以仪表板格式呈现。

• 减少每个 vCenter Server 的虚拟数据中心数量。原因：消除不必要的复杂性。

• 调查将青铜和银色集群合并。原因：可能提供更大的整合比率，同时也降低了环境的复杂性。

• 将服务器 OEM 的vSphere 安装包（VIB）仓库添加到 vCenter 更新管理器，以便通过 vCenter 更新管理器更新服务器 OEM 特定的软件和驱动程序。原因：这为 vCenter 更新管理器增加了额外的补丁功能。

• 配置巨帧以启用更快的 vMotion 事件。原因：为了启用更快和更高效的 vMotion 事件，这允许 ESXi 主机更快地疏散。

• 确保所有 ESXi 主机都正确授权。原因：这减少了在 DR 场景中需要授权主机的需求，并确保在需要时 ESXi 主机以适当的配置连接到 vCenter 服务器。

• 配置 SSO 默认域配置功能以允许更简单的登录。原因：简化用户登录。

• 在 SSO 中将本地操作系统作为身份源移除。原因：提高安全性和可审计性。

• 为模板和 ISO 创建专用数据存储。原因：消除在虚拟机部署期间或访问 ISO 镜像时可能出现的性能问题。

• 移除配置和运行中的操作系统类型不匹配。原因：提高虚拟机与 VMware Tools 之间的兼容性。

虚拟数据中心

每个 vCenter 服务器将有四个虚拟数据中心，与各种网络区域相关。虚拟数据中心结构是一个管理边界，但不需要创建多个实例，如果没有完全隔离各种 vCenter 结构的需求。四个虚拟数据中心仅用于放置vSphere 分布式交换机（VDS）。ESXi 主机和网络需要在新的单个虚拟数据中心中重新创建。这项活动应仅在有充分研究和规划的情况下进行。

以下是对虚拟资源的配置建议：

• 每主机虚拟机密度：运维团队确保他们在不同的集群上运行所有必需的虚拟机，并且不会过度承诺内存。他们还可以决定使用每个主机最多 90%的可用内存容量。他们在扩展虚拟机时使用资源单位的概念，每个 RU 相当于 1 个 vCPU 和 4GB RAM。

• 整合比率建议：他们有一个一般规则，即 vCPU 与 pCPU 的比例应小于 3:1。这个比例通常有助于 ESXi 主机上的 RU 限制。这个比例应结合每个虚拟机的特定应用、CPU 配置和利用率以及虚拟机所在 ESXi 主机的性能指标来指导。整合比率和 vCPU:pCPU 比率可能受到以下参数的影响：

  • 工作负载感知：并非所有工作负载都是相同的；一个 4vCPU 虚拟机不会与另一个配置相同的 4vCPU 虚拟机具有相同的表现特性。

  • 虚拟机配置：由于 RU 模型的限制，可能会有不必要的额外开销，这会影响整体整合比率。通常，最佳实践是虚拟机应仅配置所需的资源，以减少具有多个 vCPU 的虚拟机对称多处理带来的负面影响。由于 RU 模型是固定模型，对 RAM 需求增加的虚拟机必须配置更多的 vCPUs，即使这些 vCPUs 不是必需的。

  • ESXi 性能指标：保持固定的 CPU 整合比率通常不推荐。相反，考虑前述详细考虑因素以及两个重要的 ESXi 主机指标，将有助于更深入地理解潜在的整合比率。

  • CPU 就绪率：虚拟机准备运行但无物理 CPU 可用于调度请求的时间百分比。一般来说，应避免超过 10 的值。

  • 仪表板和超级指标：vROPs 可用于创建强大且信息丰富的仪表板。始终需要确定用例，如下所示：

    • 容量规划仪表板：RU 计算是通过从单个集群获取数字并使用电子表格来确定容量来完成的。创建仪表板并使用指标/超级指标来确定对客户而言“完整”的含义将减少所需的手动任务。这也可以与警报结合使用，提供关于集群容量的主动警告。

    • RU 模型仪表板：包含受 RU 模型影响的指标仪表板；CPU 或内存的未充分利用，以及受对称多处理（SMP）影响的 ESXi 主机指标。我们可以确定仪表板的使用案例并按需创建它们。

vROPs 拥有强大的警报引擎，可以基于动态或静态症状阈值。有许多来自 VMware 和第三方合作伙伴的现成警报，它们为 vROPS 创建了解决方案适配器。始终需要解决由 vROPS 产生的初始警报数量，因为这既是识别和修复识别出的问题的机会，也是调整现有警报和症状以及/或创建更适合环境的新的症状和警报的机会。可以使用自定义组和配置文件来创建细粒度的监控方法。生产 SQL 集群的指标可能与非生产文件服务器大相径庭。使用自定义组和配置文件可以使警报针对特定环境进行微调。这可以确定如何实现 vSphere 环境的警报，并确定 vROPS 是否能够满足这些要求，如果是，则按需进行配置。

使用 vRealize Suite 的 IaaS 解决方案

vRA 包含多种分组机制。管理员可以使用这些分组结构来组织计算基础架构，以及创建业务级别的分组来划分服务、资源和用户。

今天，应用程序正在全球混合 IT 基础设施中运行。我们必须将私有数据中心扩展到公共云以及容器中。还可以通过连接物联网服务提供商来扩展。NSX 是一个统一的网络和安全平台，适用于所有先前技术或基础设施，允许客户连接、保护并运营，以便在任何应用程序托管的地方提供服务。它包含一个内置的安全引擎，通过微分段来分割网络，并加密传输中的数据。

当我们谈论云时，我们基本上希望通过一个工具来配置和管理混合网络环境。我们不希望每个云管理系统都在孤岛中运行，对于本地部署也是如此，它应该对当前的工作负载所在位置以及未来将迁移到何处视而不见。我们应该能够将安全策略与工作负载一起迁移，无论它们托管在何处。

开发者不希望我们参与开发路径，但我们不能让开发者离开这些新技术。运维团队必须帮助开发团队熟悉这些新工具。IT 管理员有责任设置防火墙并确保没有安全漏洞。开发者不需要负责创建安全策略，他们只需消费由 IT 管理员设计的安全组即可。目标是拥有一个云配置解决方案，Devops 团队的工作量最小。我们必须为应用程序提供一致的联网和安全。

NSX Cloud 是 NSX 功能在公共云中的扩展，并不是一个独立的产品。当我们为我们的本地环境加载 NSX 时，我们已经有 90% 的 NSX Cloud 所需的功能。NSX 已经通过我们的逻辑网络结构抽象了物理/本地网络。现在，通过 NSX Cloud 提供对所有云中所有流量流的可见性，我们就可以在公共云中复制同样的功能。我们无法保护我们看不到的东西。开发者创建新的虚拟机时，IT 管理员需要有一个仪表板和一些类型的用户界面，使他们能够看到这些信息。我们必须设计一个统一的、一致的本地和公共云安全策略，以便我们能够提供高级 L2/L3 网络功能；或者如果我们正在为本地网络创建逻辑拓扑，那么可以从本地到云端口网络拓扑。管理和操作需要一个单点玻璃式的管理界面，因为这是我们想要为 NSX Cloud 实现的核心。我们使用的部署流程或工作负载，例如 Ansible 或我们用于开发者部署工作流程的任何其他工具，都不会因为使用 NSX 而改变。这是我们看到 Azure 和 AWS 以及每个公共云提供商所提供的关键价值主张之一。然而，它们都附带一些限制（特别是在规模上），这正是 NSX 区分自己的地方。显然，我们不想被锁定在某个公共云提供商的产品中。

商业级管理和组织分组

NSX 帮助客户配置多层安全。NSX 防火墙将提供主要安全，由 NSX 管理的 AWS 安全组将提供第二层安全。它可以完全配置到每个 VPC，并带有排除列表。它为测试/开发中的虚拟机部署/拆除提供了敏捷性，同时保持生产 VPC 的结构完整性，以实现两者的最佳结合。

在某些环境中，我们可能会说 VPC 需要完全上线。在某些环境中，有些虚拟机有代理，而有些没有代理是可以接受的。这是一个典型的测试和开发环境，或者是一个已经运行虚拟机的棕色地带环境，我们可能不想在所有虚拟机上安装代理，但这并不意味着它们可以被隔离。

如果我们有一个生产 VPC，并且其中有一个安装了代理的虚拟机正在运行，并且有人设法进入并安装了一个恶意虚拟机，那么我们有可能检测到它并将其隔离。

我们有一个网关在那里，它不断地轮询 VPC/VNET 内部正在创建的新资源。网关期望虚拟机中的代理来注册自己，如果没有，网关会将虚拟机移动到隔离安全组。我们可以通过使用默认的隔离策略设置来实现这一点。由于代理不存在，NSX 公共云网关（PCG）无法推送任何策略到那里，但这并不意味着 NSX 无法控制虚拟机本身。NSX 可以与云提供商通信并将此虚拟机移动到隔离状态。这就像增加了一个安全层，如果我们有一个运行的代理，PCG 可以推送策略并管理虚拟机。如果代理不存在，PCG 可以将整个虚拟机移动到隔离状态。由于 PCG 是执行此任务的一方，我们不必担心与本地系统的连接丢失。PCG 被分配了身份和访问管理（IAM）角色，这使得它可以与云库存通信。这是受专利保护的，我们不需要管理员权限来做任何这些。我们可以向客户提供云权限模板，其中他们可以为 NSX Cloud 中的每个组件分配角色和权限。PCG 将被赋予必要的角色，以便能够与云库存管理器通信并将特定资源移动到隔离状态。

我们需要一个具有本地安全组的代理来获得无代理解决方案。如果 AWS、Azure 和本地部署都采用相同的工作方式，那么我们就可以轻松地做到这一点。一个单一的政策就足以适用于所有这些环境，但这并不是实际情况。我们可以在 Azure 中为每个虚拟机应用一个安全组，我们可以在 AWS 中有五个嵌套的安全组。我们无法在 Azure 中嵌套安全组，因为我们还必须在 Azure 中为 VNET 编写第三个安全组。我们现在谈论的是安全组爆炸，但在 NSX Cloud 中我们没有遇到这些问题。在 AWS 中我们不能有一个拒绝规则，因为我们只能有一个允许规则。如果我们说不要允许特定实例的 web-web 层通信，它不会接受。任何不属于允许规则的东西都会被隐式拒绝。

我们还没有看到在代理上进行加密的任何强大用例，但我们确实为所有任务定义了以下基于角色的用户：

• VPC 应该被管理（云管理员）

• 标记虚拟机（开发者）

• 添加代理（开发者）

然而，如果我们需要在公司内不同群体或部门之间提供额外的隔离，或者需要特定租户的品牌标识，可以配置多个租户。每个租户都可以拥有专用的网络组，或者如果需要，可以共享网络组资源。他们有两个或三个订阅，在这些订阅中有大量的虚拟机，而其他场景可能有多个订阅。VMware IT 的工作是管理 AWS 和 Azure 账户。这里的每位员工都有自己的 AWS/Azure 账户，但责任在于 IT 确保我们通过移除多个安全接触点，从一个安全接口出发。将安全组分配给 VPC 和 VNET 的问题在于，这必须为每个 VPC/VNET 手动/静态完成。作为 IT 管理员，我们有两种方法来处理这个问题：让用户为工作负载创建 VPC，或者对它们施加安全限制。但在这里，安全更像是一种事后考虑。如果我们正在寻找所有 VPC 和 VNET 的安全组整合，那么我们需要一定程度的抽象。如果我们想要一个可以跨越环境的网络安全组，那么我们需要一个像 NSX 这样的工具。我们可以在 NSX-T 环境中使用 NSGroups 创建 NSX 安全策略。NSGroups 可以通过动态属性创建，例如虚拟机名称、虚拟机的位置、它运行的 VNET、它运行的区域等。它也可以基于用户定义的自定义标签，例如应用程序正在运行的内容等。NSX 可以了解这些标签，将它们带回 NSX Manager，并根据这些标签创建一些安全组并将它们应用到 NSX Manager。

Azure 存在其他限制，例如我们每个虚拟机只能有一个网络策略组（NSG），但与 NSX Cloud 相比，我们不会遇到任何此类问题。我们可以使用 NSX 的任何超集 NSGs。虚拟机可以根据元数据和虚拟机名称成为多个安全组的一部分。策略可以基于属性，而不是基于虚拟机或接口虚拟机，并且对安全组堆叠的数量没有限制。策略可以更动态地定义，而不是静态地定义到特定的虚拟机、入站或出站访问列表等。

vRA 部署

vRA 虚拟设备基于 SUSE Linux。该设备运行常见服务，例如授权、审批、通知以及组件注册服务，这允许分布式系统中的其他服务被发现。该设备还具备几个集成点，用于与轻量级目录访问协议（LDAP）和 vCenter Orchestrator 接口。vRA 设备还包含一个嵌入式的 Postgres 数据库。

服务目录包含所有配置的服务和目录项。这是一个通用目录，可以被 vRA 和其他解决方案，如应用总监，用来填充项目和服务的条目，例如机器蓝图、应用服务和基于 vRealize Orchestrator 工作流的服务。最常见的服务由 vRA 虚拟设备托管。高级服务设计器（自定义服务设计器）将 vCenter Orchestrator 工作流作为目录项暴露，IaaS 组件是 Windows 组件，它处理与预留、蓝图、端点、工作流等功能相关的功能。以下配置将在 vRA 虚拟设备中启动：

• 组件注册表-服务，允许其他服务被发现

• 认证-用户认证

• 授权-控制访问

• 审批-审批策略

vRA 设备通信

以下是通过 vRealize 组件监听的入站端口的列表：

端口	协议	注释
22	TCP	SSH
80	TCP	重定向到443
111	TCP, UDP	RPC
443	TCP	访问 vRealize Automation 控制台和 API
5480	TCP	访问 Web 管理 UI
5488, 5489	TCP	管理
7444	TCP	通过 HTTPS 的 SSO
8230, 8280, 8281	TCP	内部 vRealize Orchestrator 实例

以下表格显示了出站端口的列表：

端口	协议	注释
25, 587	TCP, UDP	SMTP 用于发送通知电子邮件
53	TCP, UDP	DNS
67, 68, 546, 547	TCP, UDP	DHCP
80	TCP	用于获取更新的可选
110, 995	TCP, UDP	POP 用于接收通知电子邮件
143, 993	TCP, UDP	IMAP 用于接收通知电子邮件
123	TCP, UDP	直接使用 NTP 同步而不是使用主机时间
443	TCP	通过 HTTPS 的 IaaS 管理器服务

IaaS 组件安装在 Windows 主机上，包括模型管理器、管理界面、执行管理器和数据库。与 vRA 一起安装的模型管理器包括从 VMware 可用的所有默认模型。

模型是一组构成配置过程元素的集合，包括数据模型、逻辑、事件定义、安全性和分布式执行管理器（DEM）与外部系统通信的规范。数据库存储配置、工作流以及 vRA 环境中所有对象的信息。

vRA 有一个 vRA 设备和 IaaS 组件。身份设备是一个基于 Linux 的虚拟设备，为 vRA 提供单点登录功能。vRA VA 也是基于 Linux 的，提供用户界面和几个常见服务。IaaS 组件安装在 Windows 主机上，包含处理和执行请求的工作流的管理服务、代理、模型管理器和执行管理器。

作为身份服务一部分运行的服务

以下是在身份服务中运行的服务：

• VMware 目录服务：由于 VMware 目录服务本身就是单点登录（SSO）安装的一部分，因此此服务将始终在与其他 SSO 服务相同的机器上运行。没有将其作为远程服务运行的选项。"vmdir"是 VMware 目录服务。

• VMware KDC 服务：这是一个 Kerberos KDC，可以帮助为VMware 证书授权机构（VMCA）服务生成票据，该服务是一个符合 x.509 标准的证书授权机构。VMCA 服务依赖于它来正确运行。它还支持证书的颁发和撤销。身份管理服务负责接收认证请求并将它们路由到定义的目录或身份源。这是一个重要的步骤，以便全球支持服务知道认证过程中出现的任何错误大多会在这里发生。

• VMware 安全令牌服务：安全令牌服务（STS）负责在验证用户的身份后颁发安全令牌。此服务运行 Tomcat 服务器。此服务负责在用户认证后颁发令牌。与这些服务相关的所有日志都位于已识别设备上的/storage/log/vmware目录中。

用于与 vRA 组件通信的 API 接口与身份管理服务和简单对象访问协议（SOAP）接口。vRA VA 和 IaaS 组件的接口都使用 HTTPS 的表示状态转移（REST）。客户可以使用 API 构建自己的 vRA 接口。

通过创建不同的资源服务层级并使用预留策略，可以进一步将分配给特定组的资源进一步细分。每个租户内可以创建多个业务组。业务组可以共享来自同一织物组的资源，或者利用不同的织物组以实现组间资源的更大隔离。如果我们需要在公司内不同组或部门之间提供额外的隔离，或者需要特定租户的品牌，则可以配置多个租户。每个租户都可以拥有专用的织物组，或者如果需要，可以配置共享的织物组资源。vRA 支持时区、欧洲日期格式和主要货币。

CF 的真正美之一是它围绕工作域提供的自动化，以及它如何使部署和扩展工作域变得非常容易。此外，通过删除工作域，它还使得回收容量变得非常容易。从配置物理服务器到配置交换机上的 VLAN 和 IP 地址，再到部署 vSphere、设置 vSAN 以及部署和配置 NSX，所有事情都完成了。工作域之间存在一些共享方面，其中之一就是我们有一个运行着两个用户定义的 VI 工作域的管理域。

在配置 VDI 工作域之前，审查 SDDC Manager 中虚拟桌面基础设施（VDI）的全局设置是个好主意。这些设置允许管理员定义桌面和 Horizon 服务器的命名、大小和 AD 放置。NSX 还为 VDI 工作域提供微分段。已经自动创建了 26 个规则集，以提供 VDI 组件的微分段。

一个完整的解决方案，能够达到预期的效果

运营团队在创建新的虚拟机以及手动部署应用程序时将涉及大量工作，这存在人为错误的风险。我们必须将整个基础设施迁移到私有云，并自动化端到端流程，以提高运营团队的解决时间。

运营团队利用由 vRealize 套件驱动的 VMware 内部私有云来提供 IaaS，包括计算、存储和网络资源，以在这些服务之上交付所有应用程序。他们能够实现完全自动化的管理功能，以控制他们的应用程序开发生命周期流程。vRealize 解决方案是可扩展的，可以利用自动化脚本来集成第三方工具，例如负载均衡器、监控代理和代码库。

以前，开发者通常需要调用运营团队来创建新的应用程序实体，这需要几周的时间来配置，但现在开发者和技术测试人员可以通过自助门户来获取新的或管理他们的应用程序景观，以定制他们的需求。在环境配置和测试完成后，开发者将获得一个包含登录详情和用于监控环境不同指标的 Web 控制台的应用程序实体链接。他们现在将在几小时内获得完全运营和测试的服务。

摘要

VMware 运维团队通过 vRA 为他们所有的应用程序及其配置创建了模板。这个自动化工具将端到端应用程序部署时间从几周缩短到 36 小时。我们在第一年后将整个周期缩短到不到 24 小时。自动化不仅有助于快速部署，还能在重复任务中保持一致性。我们可以通过自动的、预定义的政策快速构建开发和测试实验室，从而避免任何人为错误。VMware 工程师现在可以将其时间用于新的开发，并帮助他们的运维团队变得更加敏捷。员工可以通过自助门户发起和执行他们的任务。这意味着应用程序可以在几小时内部署，因此开发团队有更多时间用于新项目。这提高了 VMware 开发者的效率，也降低了由于恶意代码和积压工作带来的安全风险。基于 VMware 私有云的 IaaS 还有助于在年度节省资本支出（CapEx）和运营支出（OpEx）成本。VMware 能够降低成本并提高对最终客户的服务质量。他们更加关注产出和快速响应，以实现服务敏捷性，从而改善客户体验。我们对我们的自动化交付流程感到满意，但我们也可以通过使用混合云模型，基于 VMware 软件定义服务开发其他流程。我们必须通过定期升级 IT 服务以满足业务需求，在这个市场上保持竞争力。

在下一章，第十一章，物联网网络转型，我们将了解 VMware Pulse IoT 在不同领域（如健康、研究、科学和零售）的应用案例。我们将学*从数据中心到云再到边缘设备的应用和数据利用，通过物联网网络转型来理解如何管理和处理边缘设备上的大量数据。

第三部分：通过机器学*处理大数据、高性能计算（HPC）、物联网（IoT）和云应用的可扩展性

新的 vSphere Scale-Out 版本专门设计用于运行高性能计算（HPC）和大数据工作负载。我们必须确保 HPC 和大数据性能以及其他要求可以通过开发或通过使用我们主流产品的微调指南来满足。这个 vSphere 版本包含了一组调整过的功能集，以适应这两种 Scale-Out 工作负载类型，即 HPC 和大数据，并且具有有竞争力的成本。它包含了大数据和 HPC 工作负载所需的所有核心 vSphere 功能，并以 8 个 CPU 的套件销售。vSphere Scale-Out 版本包含的关键特性包括 ESXi 虚拟机管理程序、vMotion、存储 vMotion、主机配置文件、自动部署和分布式交换机。

本节包含以下章节：

• 第十一章，使用物联网进行网络转型

• 第十二章，在 vSphere 上虚拟化大数据

• 第十三章，云应用扩展

• 第十四章，高性能计算

第十一章：物联网网络转型

本章将简要介绍软件定义数据中心（SDDC）如何跨越多个数据中心并进入混合服务提供商，无论物理基础设施如何，都可以拥有分布式的数据和应用程序。数字化转型正在改变商业模式，物联网（IoT）在这一转型中发挥着关键作用。商业增长正在加速，探索以现代数据中心快速将新产品和服务推向市场的方法，这种数据中心可以提供推动创新和增长所需的敏捷性、安全性和可扩展性。我们将了解客户在物联网实施中寻找的核心需求。

我们将了解为什么物联网（IoT）对健康、研究、科学和零售客户如此关键，因为他们的应用和数据将从数据中心到云再到边缘设备得到利用。我们还将通过了解如何在边缘设备上管理/处理大量数据，以及 VMware Pulse IoT 在不同垂直领域的用例，来探讨物联网网络转型的变化。

我们将涵盖以下主题：

• 物联网和机器学*（ML）

• 物联网需要混合云来超越区域边界进行管理

• 分布式网络

• 虚拟云网络下的安全

• VMware Pulse IoT Center

技术要求

您可以从my.vmware.com/web/vmware/details?downloadGroup=PULSE_IOT_110&productId=751&rPId=23122下载 VMware Pulse IoT Center 1.1.0，以及从my.vmware.com/en/web/vmware/info/slug/networking_security/vmware_nsx_t_data_center/2_x下载 VMware NSX-T Data Center。

物联网

物联网用例存在于大多数行业中。它们可能对我们不明显，甚至可能对客户也不明显。物联网是一个工具，企业使用这个工具来实现更好的结果。他们在处理依赖于物联网工具的模式时是一致的：摄取、分析和参与。物联网解决方案摄取来自传感器和设备的数据，分析组件然后使用这些数据得出结论（分析），结果触发动作，使企业能够参与与基础设施或其客户的互动。

企业使用摄取、分析、参与来不断改进他们的产品和服务；这种主动或被动的反馈可能来自人类、计算机、卡车或生产线。市场上观察到的物联网用例可以分为三个高级 IT 价值管理目标：

• 持续客户参与

• 数字参与

• 新商业模式

让我们来看看一些这些用例：

• 治疗依从性允许医疗机构通过使用智能药盒来监控患者是否遵循他们的治疗方案

• 在保险行业中，智能检查允许使用无人机和图像识别来检查损坏

• 矿业公司使用预测性维护来安排重型基础设施的预防性维护，因为维护直接影响生产力

• 想象一下给你的车添加一个新的运动驾驶模式，就像在苹果商店或谷歌应用商店购买应用一样——这就是软件功能交付在汽车领域可以实现的

• 基于风险的定价推动汽车保险，使保险公司能够根据连接到车载计算机的设备测量的个人驾驶*惯来定价保险

• 自动结账，正如亚马逊和沃尔玛正在试验的，允许顾客购物无需排队

• 智慧城市在最*一段时间内一直是新闻的焦点。这些城市能够实现高效的能源消耗和更安全的道路

在每个用例中，都明显体现了“摄取、分析、参与”的理念。

VMware Pulse

VMware Pulse IoT Center 是一个安全的企业级物联网设备管理和监控解决方案。您可以从边缘到云，管理、监控和确保物联网用例，弥合 IT 和 操作技术（OT）组织之间的差距，并通过 Pulse IoT Center 简化物联网设备管理。Liota Agent 在边缘系统中启用数据编排，自动检测边缘系统，并将边缘系统映射到连接的设备上，从而实现自动上载和配置空中传输（OTA）。它收集关于基础设施健康状况的遥测数据，并实时以高精度检测异常。它通过配置规则以灵活的包组合升级，管理任何边缘类型的软件 OTA 以及连接的端点。

通过创建分段的数据流，使用网络虚拟化提供对所有事物的完全可见性，它为物联网事物、网络、数据和人员提供安全性。我们首先必须发现客户痛点，这些痛点阻碍了他们的业务增长，并减缓了他们的整体流程。

与 VMware Pulse 相关的查询

以下是与 VMware Pulse 相关的查询

使用以下探询问题发现客户痛点，这些问题适用于大多数客户：

• 在设备 OTA（固件/软件更新）方面面临安全挑战

• 寻找远程、无人操作的物联网设备，例如，位于海洋中的油井平台

• 从测试到公司范围内实施的转变中遇到困难

• 寻找在本地部署物联网管理解决方案的选项，并拥有更多数据隐私控制权

• 网络中正在快速添加新的端点

• IT 对物联网部署没有可见性或控制权

• 在物联网设备方面面临合规性挑战

• 有太多不同的专有管理工具

• 从连接的物品/硬件中获取指标面临的挑战

• IT 需要一个允许与 OT 协调进行更改的解决方案

城市采用物联网解决方案的发现问题：

• 智慧城市或市政物联网项目包括哪些内容？

• 我们是否有计划增加摄像头监控以保护公民？

• 我们计划如何监控、管理和保护诸如摄像头和道路传感器之类的设备？

这里有一些针对采用物联网项目的医院的调查问题：

• 每年有多少医疗设备丢失？（据统计，大约 30%）

• 我们是否了解连接到我们网络的所有事物（硬件）以及它们是否安全？

• 我们是否考虑过跟踪我们的设备？这将解决一些关于它们位置和状态的知识痛点吗？

• 如果我们能监控我们的患者和医生的位置，我们能否利用这些信息来提高患者护理的质量？

• 目前医疗设备的预防性维护是如何进行的？

这里有一些针对采用物联网技术的设备制造公司的调查问题：

• 我们今天提供预防性维护服务吗？我们是如何做的？

• 我们如何确保我们用于机器（车辆等）内部的技术工作准确并报告正确数据？我们是如何保护它的？

• 我们能否为我们的客户更新软件设备 OTA？您是否给了我们的客户自己这样做的能力？

• 我们是否有智能工厂或工业 4.0（自动化和数据交换在制造技术中的当前趋势被称为第四次工业革命）项目？

• 实施工业 4.0 的最大障碍是什么？

• 如果我们能帮助监控、管理和保护异构物联网环境，会怎样？

• 如果我们能与 OT 合作以确保物联网项目得到管理和保护，会怎样？

Pulse IoT Center 基础设施管理蓝图

OVA 基本上是一个包含三个虚拟机（VMs）的 vApp，这些虚拟机运行 Ubuntu 服务器。默认情况下，这些虚拟机的命名如下：

• mqttbroker：这安装了来自http://emqtt.io的 EMQTT 代理

• iceapi：这预装了 VMware Pulse IoT API 和 PostgreSQL

• iceconsole：这包含带有所有依赖项的 VMware Pulse IoT Console

在部署期间，OVAs 将需要一些特定于应用程序的属性来帮助初始化自身。这些属性基本上用于配置每个虚拟机中的应用程序。

部署和配置 OVA

OVA 可以通过 vSphere 使用 vSphere UI 中的“部署 OVF 模板”或使用命令行中的 OVF 工具进行部署。在第一次启动虚拟机之前，请确保为主机启用了客户端操作系统定制，以便为每个客户端操作系统注入正确的系统和网络设置。

客户端操作系统定制向导如下所示：

部署还会要求输入一些属性，以帮助设备在一定程度上进行配置。添加一个 EMQTT 凭据（用户名、密码），以便在 VM 首次启动时，代理启动时使用此预置用户。这不是系统用户，而是客户端可以用来连接到代理的 EMQTT 用户。只能通过此选项配置一个用户名和密码。任何额外的用户都必须在登录到mqttbroker VM.后从命令行创建。用户名和密码长度应在 8 到 64 个字符之间。建议您将用户名保持为纯字母数字。此密码不用于任何内置的 Linux 用户账户。

同样，向导会要求输入物联网 API 和物联网控制台的密码。物联网 API 的密码将用于保护数据库和生成的证书。物联网控制台的密码仅用于生成的证书。用户名和密码长度应在 8 到 64 个字符之间。建议您将用户名保持为纯字母数字。此密码不用于任何内置的 Linux 用户账户。

我们可以使用 VMWare Pulse IoT API 和控制台作为输入，通过使用 MQTT 代理的公共 DNS 名称来生成 SSL 证书。这些值在证书生成过程中使用。该名称将包含在生成的 SSL 证书的 CN 和 SAN 部分。因此，在继续部署之前，有必要冻结域名，以防您需要继续使用带有自签名证书的服务器。

例如，以下是一些部署的功能：

• EMQTT 用户名和密码为vmwareiot和vmwareiot

• 物联网 API 数据库和证书的密码

• 物联网控制台证书的密码

• EMQTT 服务器的公共 FQDN：demoemqtt.vmwpulse.com

• VMware Pulse API 服务器的公共 FQDN：demoapi.vmwpulse.com

• VMware Pulse IoT 控制台服务器的公共 FQDN：democonsole.vmwpulse.com

• 时区设置可以保留为默认设置

通过导入向导配置的设置如下所示：

我们将学*关于特定于 Pulse IoT 中心的产品的安装和配置。部署需要按照以下顺序进行，以解决依赖关系：

• VMware Pulse 设备管理套件

• 带有 Helix 适配器支持的 VROPs 套件

• EMQTT 代理

• VMware Pulse IoT 中心控制台（UI）

• VMware Pulse IoT 中心 API 服务器

• 支持单点登录（SSO）的 vIDM

在部署 VMware Pulse IoT 中心组件之前，请确保在部署基础设施中所有计算和网络资源都可用，无论是 VMware OneCloud 还是 VMware vCenter。OVAs 默认没有启用防火墙或 iptables 规则，留待部署团队根据需要添加额外的安全强化或加固。

配置物联网支持

projectice是一个没有sudo权限的标准 Linux 用户，用于运行 VMware Pulse IoT Center 组件。VMware Pulse IoT Center 控制台、Hazelcast 和 VMware Pulse IoT Center API 服务器作为系统服务在此账户下运行。服务作为守护进程运行，以支持系统重启时的自动重启。此账户未设置密码，因此，只能通过另一个登录会话使用sudo或su进行本地登录。此用户仅限于 Pulse IoT API 的虚拟机和 Pulse IoT 控制台的虚拟机。EMQTT 代理虚拟机没有此用户。同时存在 root 账户，默认密码为vmware。所有默认密码在首次登录时都需要更改。

在安装之前，需要满足以下先决条件：

• SSL 证书。

• API、控制台服务器和 EMQTT 代理的有效域名。该名称应反映在 SSL 证书的通用名称和 SAN 中。

• 在启动虚拟机之前，在虚拟机上启用“来宾操作系统自定义”，以确保虚拟机配置了正确的主机名和网络设置。

• 虚拟机托管环境，如 vCloud 或 vSphere。

OVA 中的虚拟机

iceadmin是一个具有sudo权限的管理员用户，主要用于 VMware Pulse IoT Center 组件的配置和管理。VMware Pulse IoT Center 组件通常是系统服务，iceadmin账户将根据需要用于安装/启动/停止/重启服务。这种服务管理需要一个具有管理员权限的用户。此账户的默认密码是vmware，不带引号。

安装后，需要在“设置”|“设备与用户”|“高级”|“IoT 支持”中启用 IoT 支持：

此部分应在安装 IoT API 服务器之后进行配置。VMware Pulse IoT API 注册来自 VMware Pulse Device Management Suite 的通知，以加快资源刷新的速度，而不是依赖于同步间隔。这有助于 Pulse IoT API 保持资源的合理精度。以下事件发生时，这些通知将从 VMware Pulse Device Management Suite 发送到 Pulse IoT API：

• 新设备已注册

• 设备已注销

• 设备更改其组织组

VMware Pulse Device Management Suite 和 Pulse IoT API 仅在设备属性更改标志在事件部分启用时，才尊重设备的属性更改通知，例如资产编号、设备友好名称、组织组 ID、用户电子邮件地址、所有权、操作系统、电话号码或设备 MCC。VMware Pulse Device Management Suite 仅支持组织组更改，这是在同一 OG 树内完成的，即在其子 OG 中。该事件在一段时间后通知给监听器。

在 Windows 服务器上安装 Pulse 设备管理套件控制台时，VMware Pulse 设备管理套件安装程序建议您启用 TLSv1.2。请确保启用 TLSv1.2，或者如果错过了此步骤，请按照之前概述的手动步骤执行。始终确认以下键已持久保存在注册表中。这是设备通知被通知到 VMware Pulse IoT API 服务器所必需的注册表条目。

检查以下 Pulse 设备管理套件物理服务器中的注册表键：

"HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\SecurityProviders\\SCHANNEL\\Protocols
 TLS 1.2 Client"
 Value name : DisabledByDefault
 Type : DWORD (32-bit) value
 Value : 0
 Value name : Enabled
 Type : DWORD (32-bit) value
 Value : 1

使用此注册表文件创建注册表中的设置，如果它们缺失。只需在 Windows 服务器上作为管理员用户右键单击文件并选择合并。如果 Pulse IoT API 使用自签名证书安装，请确保按照以下步骤将自签名证书的根 CA 证书添加到安装 Pulse 设备管理套件的计算机上 Windows 系统证书存储中的受信任根证书：

1. 从文件菜单中选择添加/删除插件...：

1. 从可用插件中选择证书，然后点击添加>：

1. 选择计算机账户并按下一步：

1. 确保已选择本地计算机。点击完成并按确定：

1. 在第三方受信任根证书颁发机构下的证书节点处，右键单击以导入证书：

1. 按照导入向导保存从浏览器保存的私有 CA 证书：

这将帮助在 Pulse 设备管理套件对 Pulse IoT API 进行 SSL 调用以发送通知时，SSL 验证成功。仅添加证书不会允许 SSL 调用成功，除非 VMware Pulse 设备管理套件 API 用于连接 Pulse IoT API 的主机名与为 Pulse IoT API 服务配置的实际证书相匹配。

VMware Pulse 设备管理套件需要连接到以下：

• VMware Pulse IoT API 服务器，用于发送通知

• VIDM（如果已配置）

如果通过 Windows 虚拟机内部路由可用，VMware Pulse 系统在%SystemRoot%\drivers\etc\hosts文件中为使用外部 DNS 名称的任一机器添加一个别名以避免往返。DNS 名称对于 SSL 验证发生很重要，因为每个这些服务器都是通过 HTTPS 调用的。

从 IOT 发布工件中的链接下载基于 VROPs 6.6 构建的 VMware Pulse 操作分析后端版本。要登录 VM，root 用户的默认密码将为空。因此，只需按Enter键，并在首次登录时设置新密码。此登录应从部署 OVA 的终端控制台进行。默认情况下禁用了 SSH。一旦部署并开机，请访问https://<IP 地址>上的 vROPs 实例 Web UI，它将引导您完成 vROps 的基本安装步骤。您可以选择安装/快速安装，并为 vROPs 实例提供密码。您将需要获取许可证密钥才能使用 vROPs。

VMware Pulse 的物联网用例

企业考虑和实施物联网解决方案的主要动机是通过识别客户特定的物联网用例来提高业务生产力和内部效率。在考虑物联网用例时，我们关注可衡量的目标，以展示生产力和效率的提高。无论我们注意到哪里产生数据，我们都有数据摄取的能力。这可能是尚未解决的问题，因此企业还没有对数据进行任何操作。然而，当我们观察到摄取数据的机会时，我们应该考虑分析这些数据，并使用这些结果与客户或基础设施进行互动。

在边缘系统上安装 Liota 代理以启用数据编排，自动检测边缘系统并安装和配置 OTA，并将边缘系统映射到连接的设备。我们可以监控和收集关于基础设施健康状况的遥测数据，以高精度实时检测异常，并在可能的情况下设置规则以自动修复 OTA。

我们还可以管理任何边缘类型和连接端点的软件 OTA，设置规则以灵活的包组合自动升级/修复，并设置规则以自动修复 OTA。我们可以在物联网的各个方面进行安全防护——事物、网络、数据、人员，通过网络虚拟化创建分段数据流，并对所有事物拥有完全的可见性。

根据用例需求、环境和所需的坚固能力选择网关/服务器；我们具有选择 VMware IoT edge 运行在哪种硬件上的灵活性。

VMware Pulse IoT edge 通过使用我们信任的技术在边缘进行数据分析，支持新的分布式物联网架构。接下来，我们将深入探讨一些用例。

为联网汽车提供动力（汽车行业）

• 业务问题：客户在软件相关的联网汽车召回成本上升方面遇到困难。

• 用例：OTA 更新，运营分析。

• 客户收益: 通过部署安全补丁、组件升级和新服务 OTA 和实时更新，管理这些汽车的头单元和 ECU。从车辆组件收集遥测数据，并在实时分析以检测异常，并发出管理员定义的命令和警报。降低召回率并提高汽车的保修期，以增强客户满意度和长期忠诚度。

娱乐、公园和度假村

• 业务问题: 客户在其所有物业中部署了可穿戴设备和其它传感器，以更好地跟踪客户行为、减少等待时间并优化客户体验。然而，他们发现难以应对其物联网部署的碎片化和异构生态系统，这导致管理和运营成本上升。

• 用例: 资产跟踪、OTA 更新到 RFID 基础设施、运营分析。

• 客户收益: 通过提供一种远程监控设备并交付 OTA 更新的方法，降低维护这些连接设备和基础设施的成本。确保所有连接设备都安装了最新的安全补丁和固件更新。为所有访客提供黄金标准的客户体验，最大化可持续性，并提高整体的工作效率和运营效率。

智能医院（医疗）

医生希望通过解读数据并主动检测和治疗医疗问题，收集关键信息并在护理点实时访问患者的生命体征、诊断和影像。

• 业务问题: 客户的目标是提高患者、人员和设备管理的效率并消除错误。通过实施 RFID 跟踪，可以实现对所有参与者和设备的定位识别，从而实现这一目标。

• 用例: 资产跟踪、OTA 更新到 RFID 基础设施、运营分析。

• 客户收益: 管理、监控和保障作为 RFID 标签连接点的网关。实时提供 OTA 安全补丁。通过实时运营分析帮助深入了解设备生命周期。提高患者、人员和设备管理效率，消除错误，并在处理、资源配置和设备使用方面实现改进。

智能监控（高等教育）

• 业务问题: 大学希望提高校园内学生和员工的安全。大学计划部署 V5 系统智能摄像头，这些摄像头可以检测枪声、嗅到硫磺味等，以实时预防性地检测公共骚乱，如枪击和暴乱。

• 用例: 运营分析、资产跟踪、OTA 更新。

• 客户收益：管理、监控和保障作为 RFID 标签连接点的网关。提供实时 OTA 安全补丁。通过实时操作分析帮助深入了解智能摄像头设备生命周期。使校园对员工和学生更安全，并极大地改善应急响应。

智能仓库（零售行业）

客户希望通过自动化流程控制，以增加可见性并快速与供应商整理来料，为工人提供实时、免提的复杂组装说明访问。

• 业务问题：客户希望通过使用机器人来减少由于人为错误和疲劳导致的故障，从而在店内提高配送和发货流程的效率。他们将从管理配送中心和零售店的机器人开始，一个机器人用于扫描货架并识别缺货商品，另一个机器人用于为顾客寻找店内取货点。

• 用例：资产跟踪。

• 客户收益：管理、监控和保障所有部署的机器人，为所有业务单元的物联网项目提供一站式解决方案。在单一视图中管理所有物联网用例，并采用一致的方式管理和监控所有连接的设备。

火车互联网（交通和物流）

• 业务问题：客户希望通过能够维护他们的设备来消除/减少停机时间。

• 用例：实时设备监控，OTA 更新。

• 客户收益：实时监控物联网网关和连接的空气压缩机，以确定设备是否离线。向合作伙伴的网关提供操作系统和软件更新。

客户将拥有一个系统来远程监控空气压缩机和其它设备，通过与 VMware 合作将提高效率并降低成本。

金融行业

• 业务问题：创建未来的银行并改善数百个零售银行（如识别到达的客户和预测他们可能需要的服务）的客户体验。此外，分行经理每天在银行关闭前必须完成一系列任务（如保险库、出纳员抽屉等），但目前没有可靠的方法来确认每一步都已完成。

• 用例：实时设备监控，OTA 更新。

• 客户收益：远程管理和监控物联网基础设施（网关、传感器、信标、摄像头等），确保设备在线且安全。Pulse 提供了一个单一控制台来管理实现未来银行所需的多种物联网设备，并确保银行运营不受干扰。

智能天气预报

• 业务问题：客户希望使用物联网部署传感器以获取有关天气和季节性模式的更丰富数据，以便向公众以及进行研究。该局正在部署数千个气象监测站点，由于它们位于偏远、无人值守的地点，因此无法轻松集中管理或保护。

• 用例：单点管理、监控/警报、OTA 更新。

• 客户收益：为存在于多个气象监测站点的网关设备和相应传感器提供一个安全中央控制点。实时提供 OTA 安全补丁。通过实时运营分析帮助深入了解智能摄像头设备生命周期。能够成功从所有传感器获取标准化图像和集中化数据，为公众、气象科学家和国际合作伙伴提供气象监测、预报、趋势和警报。

物联网数据中心网络安全

物联网流量与数据中心网络流量不同，因为通信变得数字化，控制实例成为从本地数据中心到云的控制中心。

有三个新的大规模横向（东西向）流量区域：

• 边缘计算：即连接自动售货机的局域网

• 数据中心内部：不同应用程序、存储和数据库之间的不同目的（计费、分析、控制）

• 跨数据中心：数据中心中不同客户的应用程序之间的交互（订单、制造、运输）

带有新路径和新内容的新流量具有大量东西向敏感私有数据，而今天的应用程序被分散到数百个要么相同（负载均衡）要么互补（工艺链）的实例中，而每套数据收集都将由数据中心的不同应用程序多次（随时间）处理。它们的东/西向流量高度动态，因为应用程序实例的来去。这些应用程序经常更新，其中大部分敏感数据被处理和存储。我们应该准备自己，以防止、检测和在高动态环境中遏制漏洞。

我们可以应用以下策略和主动措施来避免任何安全漏洞：

• 分布式防火墙（DFW）：通过在接口处对每个实例进行微分段来保护和过滤每个实例。人们无法伤害他们无法触及的东西。

• 客户内省：观察每个实例中的数据和行为，通过发现症状并防止其执行来检测数据泄露或潜伏的恶意软件。

• 网络内省：在空中观察第 7 层网络流量以保护宝贵数据，并通过在跨越层级时关闭口袋来保护实例。随着我们将数据中心从购物中心转变为监狱，我们必须通过一个引擎自动化或失败整个流程，以获得并维持一致性。

• 自动化修复：我们发现被入侵的实例并通过进行客户内省立即将其隔离。

• 自动化一致视角：允许 OPS 从声明性视角在整个孤岛之间拥有整体视图。

NSX 分布式防火墙

我们可以通过解耦网络和安全来在每个 vNIC 上部署逻辑防火墙。每个 vNIC 上的防火墙实例尽可能接*嵌入在虚拟机管理程序中的任何类型的 vSwitch，但不属于虚拟机。我们不会将流量从源移动到检查点，而是将检查点移动到流量的源，与网络基础设施无关，不影响服务器细粒度保护。

在 vNIC 上的分布式防火墙是正确的位置，并且完全集成以最有效地应用策略。集成意味着无论我们在哪里，无论我们走向何方——即使我们偏离轨道或改变方向——它仍然有效，因为它集成在虚拟机管理程序中。集成还意味着作为驾驶员或乘客，我们不需要承担责任来穿上我们的保护，我们无法忘记或避免它，因为它集成在虚拟机管理程序中。集成还意味着它在物理和功能上与一些传感器集成，并在正确的时间触发安全气囊。NSX DFW 通过基于 vCenter/活动目录规则集的抽象和自动化来定义服务组合器中的自动化。

自动化的先决条件

数据的动态来源代表系统和抽象层的状态和变化，抽象层将在更高层次上定义以响应条件和变化。我们使用 vCenter 和活动目录来表示特定解决方案中服务器和用户的信息。NSX 管理器中的服务组合器动态地将服务定义和 FW 规则转换为接口规则集，并将它们推送到下级。

我们拥有用于抽象的必要数据的 vCenter。NSX DFW 服务组合器帮助客户立即对变化做出反应，并在每个强制性和战术性动作中声明策略。管理员无法远程控制每个组件的动作，而是定义一个策略——一系列抽象规则和措施——以控制和遵循合规政策：

控制器反过来负责将策略转换为战术动作，并协调它们，同时保持监督，特别是在情况变化时，它们特别负责立即改变战术。数据中心中的每个组件都扮演其个别角色，这是由控制器分配的。我们应该从本地数据中心的视角自动化数据中心之间的流量以及所有 N/S 流量，或者，数据中心之间的流量是 N/S 流量。

如果部署或更改因必要的 N/S 防火墙规则集的更改而无法立即上线，那么自动化本地数据中心是没有意义的。N/S 防火墙可能会消耗其规则中的 VMware 对象，因为这些对象是动态的，当实例到来或离开时，不会触及 N/S 防火墙的规则集进行日常更改。NSX 安全组可以被第三方防火墙动态消耗，这些防火墙会自动更改其规则集对象。

混合云以实现规模和分布

物理视角难以管理，需要在数据中心之间进行逻辑、连贯的操作。本地数据中心的本地数据流可能不够大且冗余，无法扩展计算，这些计算可以分散到多个数据中心。

随着更多 N/S（以及 E/W）流量进入数据中心，物联网就绪的数据中心必须遵循特定的安全和可扩展性实践。我们还需要更多的数据中心间流量，以便第三方工具集成，以实现以下目标：

• 微分段

• 声明式管理

• 集成自动化

• 分布式扩展

• SDDC 以实现一致的管理

通过虚拟化所有移动部件，我们可以实现端到端的自动化。

摘要

物联网（IoT）领域为联盟解决方案提供许多独特价值的新领域打开了大门。物联网有多种形式，例如智能恒温器、一个可穿戴的医疗设备，它可以监测患者的生命体征，或者一个智能自动售货机，它可以记住顾客喜欢的饮料。物联网是网络世界与物理世界交汇的地方。任何物联网解决方案都需要结合连接性、移动通信、管理、基础设施和安全，以及应用程序的生命周期。

客户需要一个基础设施，他们可以在其上构建物联网解决方案；然后他们需要在那个基础设施上配置和管理数百万个事物。这些事物会产生大量数据，因此客户还需要收集、存储和分析数据，从中获得有意义的见解，然后将这些见解转化为有价值的行动。我们通过提供物联网基本要素来实现这一点，使我们能够实现三个主要业务成果。

以下三个业务目标是：

• 管理数百万事物就像管理一个事物一样简单

• 利用相关数据将事物付诸行动

• 将物联网变为商业现实

在下一章中，我们将通过评估当前的内存大数据平台来学*如何利用现代大数据平台中的共享存储。我们将探讨大数据应用（如 Hadoop）如何适合虚拟化，作为这些平台内存功能的一部分，使它们减少对 I/O 和存储协议的依赖，这样我们就可以利用虚拟化的共享存储和基本的 VMware vSphere 功能来设计一个高度可用和面向性能的大数据平台架构。

第十二章：在 vSphere 上虚拟化大数据

在本章中，您将学*如何利用现代大数据平台中的共享存储。我们将评估 vSphere 虚拟化平台上的当前内存大数据应用。这些平台内存功能使得它们对 I/O 和存储协议的依赖性降低。我们将探讨管理员在创建 Hadoop 集群时的生产力和控制，并展示使用 Hadoop 管理工具在虚拟机上安装软件的方法。此外，我们将了解可扩展性和缩减性的能力，这样平台上的任何工作负载都可以通过多个虚拟 Hadoop 集群的资源共享来扩展，以利用所有可用的集群资源，从而提高平均资源利用率。

我们将详细介绍以下主题：

• 大数据基础设施

• 开源软件

技术需求

您可以从my.vmware.com/web/vmware/details?downloadGroup=BDE_232&productId=676&rPId=28154下载 VMware vSphere Big Data Extensions 2.3.2。

大数据基础设施

云实施始终包含一个服务目录，其中包含所有可供消费的服务。它还包括服务设计、目录管理和知识管理系统。这些服务将使组织能够加速运营并构建敏捷的云服务框架。我们必须定义一些角色、责任和功能来管理流程：

• 服务所有者：负责服务的价值和管理服务积压

• 服务积压管理器：负责定义包含所有积压的服务优先级，包括功能、非功能和技术需求

• 服务发布经理：负责规划、调度和控制构建、测试和发布，通过提供新功能以及照顾现有服务来负责

Hadoop 作为服务

VMware vSphere 大数据扩展（BDE）是运行可扩展集群 Hadoop 应用的平台。它通过单个控制台提供更改配置的敏捷性，以及通过 vSphere 平台提供更好的可靠性和安全性来扩展和缩减计算和存储资源：

我们将 Hadoop 之旅分为三个阶段：

• 阶段 1：这是我们所说的试点阶段；我们通常看到的集群规模在 20 个节点以下。在这个阶段，客户正在尝试了解 Hadoop 的价值，并在许多情况下，证明 Hadoop 在提供新的业务洞察力方面的价值。通常，这个过程从业务线开始，有人希望将 Hadoop 应用于一个或两个用例，通常是在企业收集但未充分利用的数据上。例如，我们与一家石油和天然气公司交谈时，他们收集了所有这些来自油井和钻平台的传感器数据。通过 Hadoop，他们进行了一些有趣的统计分析，并获得了许多有趣的见解。

• 阶段 2：一旦在大数据上证明了 Hadoop 的初始价值，企业通常会将其用例规范化，并定期作为生产工作负载运行。在这个阶段，我们常见的一个现象是，随着人们了解到这个生产 Hadoop 集群，他们希望利用它来探索他们的数据；越来越多的作业被添加到集群中，集群开始扩展和增长。我们看到的另一个常见现象是，这不仅仅关乎 MapReduce 和 Hadoop 分布式文件系统（HDFS）等核心 Hadoop 组件。Hive、Pig、HBase 等其他非核心 Hadoop 组件通常也会添加到集群中。通常，我们看到的生产集群从几十个节点到几百个节点不等，并且可能迅速增长。在这里，通常有专门的 Hadoop 管理员来确保系统的健康。

• 阶段 3：在这个阶段，客户在其整个组织中广泛使用 Hadoop，并围绕它建立了关键业务工作流程。例如，对于一家电子商务零售商，推荐引擎现在是其业务的关键部分，而 Hadoop 是工作流程的关键部分。通常，在这个阶段，我们会看到企业将 Hadoop 扩展到其他大数据技术和服务。通常，大规模并行处理（MPP）数据库、NoSQL 数据库以及更多非核心 Hadoop 组件都是大数据生产系统的一部分。在 Hadoop 节点方面，我们通常看到数百到数千个节点。在极端情况下，像 Yahoo 和 Facebook 这样的公司有数千个节点。

部署 BDE 设备

VMware 通过 vSphere BDE 使您能够轻松高效地在现有的虚拟基础设施上部署和使用 Hadoop。BDE 使 Hadoop 具备虚拟化意识，提高了虚拟环境中的性能，并能在几分钟内部署高可用性的 Hadoop 集群。vSphere BDE 自动部署 Hadoop 集群，从而提供更好的 Hadoop 管理性和可用性。

让我们从以下步骤开始：

1. 在 VMware vSphere 客户端中选择“文件”，然后转到部署 VMware-BigDataExtensions-x.x_OVF10.ova。

2. 在“选择源位置”对话框中，点击“本地文件”单选按钮，点击“浏览...”，浏览到身份设备的位置，点击“打开”，然后点击“下一步”：

1. 在“查看详细信息”对话框中，查看摘要详细信息，然后点击“下一步”。

2. 在“接受 EULAs”对话框中，通过点击“接受”按钮接受许可协议，然后点击“下一步”。

3. 在“选择名称和文件夹”对话框中，在“名称”文本框中输入虚拟设备的唯一名称。

4. 选择部署虚拟设备所需的文件夹或数据中心位置，然后点击“下一步”。对于 QA 部署，选择 East FP | Pumulus | QA 文件夹。

5. 在“选择资源”对话框中，选择您想要部署虚拟设备的集群，然后点击“下一步”。对于 QA 部署，选择 ECHADMIN01 集群。

6. 在“资源池”对话框中，选择所需的资源池。

7. 选择 QumulusQA VMs 资源组。

8. 在“选择存储”对话框中，从“选择虚拟磁盘格式”下拉列表中选择您想要为虚拟设备使用的磁盘格式。

9. 通过在列表中点击选择您希望放置虚拟设备的存储区域。点击“下一步”。对于 QA 部署，选择 ECHADMIN01-DEV 和 QA-VMX 数据存储区域。

10. 在“磁盘格式”对话框中，选择“精简配置”并点击“下一步”。

11. 在“设置网络”对话框中，使用“目标”下拉列表选择您想要连接虚拟设备的网络，然后点击“下一步”。

12. 对于 QA 部署，选择 xx.xxx.0.0/22。

13. 在“准备完成”对话框中，选中“部署后开启电源”复选框，然后点击“完成”。

配置 VMware BDE

我们将部署 vApp，开启电源，然后浏览管理服务器的控制台。在这个 vSphere 环境中配置了四个 Hadoop 集群。右侧的列视图指示每个集群的名称、状态、运行的 Hadoop 发行版、所属的资源池以及节点列表。资源池管理 Hadoop 如何消耗底层物理资源。

在 vSphere 上配置 BDE 的步骤如下：

1. 以 Serengeti 身份登录，并使用以下命令更改 Serengeti 用户密码：

run sudo /opt/serengeti/sbin/set-password –u

1. 关闭管理控制台，使用 serengeti 用户 SSH。通过运行以下命令配置 YUM 仓库：

# cd /opt/serengeti/www/yum/repos/centos/6/base/RPMS/
wget http://mirror.centos.org/centos/6/os/x86_64/Packages/mailx-12.4-7.el6.x86_64.rpm
wget http://mirror.centos.org/centos/6/os/x86_64/Packages/wsdl4j-1.5.2-7.8.el6.noarch.rpm

1. 如果我们无法使用wget连接，请下载.rpm文件，然后使用 winscp（开源工具）上传。要创建仓库，请运行以下命令：

createrepo ..

BDE 插件

我们将通过点击主页图标然后选择大数据扩展来访问 BDE 插件。

1. 打开网页浏览器，导航到https://xx.xxx.x.xx:8443/register-plugin。请记住，IP 地址将是用户特定的。

2. 选择“安装”单选按钮，填写 vCenter 信息，然后点击“提交”：

1. 在 vSphere Web 客户端中点击大数据扩展，然后在摘要选项卡中点击“连接服务器...”超链接，通过库存树导航以找到管理服务器：

1. 点击 OK 以接受证书。现在服务器已在摘要选项卡中连接。

2. 要设置 Hadoop YUM 仓库，以 root 用户身份 SSH 进入 YUM 仓库服务器。输入 VMware KB 文章中显示的命令（kb.vmware.com/s/article/2091054）以配置 Hortonworks 数据平台（HDP）2 YUM。

3. 浏览到新的仓库地址 http://puppet2.qvcdev.qvc.net/hdp/2/。我们将为此环境使用现有的 YUM 仓库服务器。

在 BDE 上配置发行版。

我们现在将通过 SSH 使用 Serengeti 用户帐户登录到 Serengeti 管理服务器：

1. 使用 PuTTY 通过 SSH 连接到管理服务器，然后在桌面上双击 PuTTY 图标。

2. 点击 SerengetiCLI 会话，然后点击打开。

3. 运行以下命令：

# navigating to the scripts directory

cd /opt/serengeti/sbin
[root@10 sbin]# ./config-dist
ro.rb \
> --name qumulusqahdp \
> --vendor HDP \
> --version 2.x.x \
> --repos http://puppet2.qvcdev.qvc.net/hdp/2/hortonworks-hdp2.repo

qumulushdp 发行版已成功添加到 /opt/serengeti/www/distros/manifest。

旧的清单已备份到 /opt/serengeti/www/distros/manifest.bak。

[root@10 sbin]# sudo service tomcat restart

1. 登录到 vCenter Web 客户端，并从左侧树中选择大数据扩展。

2. 点击大数据集群，然后点击图标添加新的集群（一个绿色的+号）。

我们现在可以在 Hadoop 发行版中看到新的 HDP 发行版名称。请注意，名称将与运行 ./config-distro.rb 时指定的参数匹配（pumulushdp）。

vRO 中的 Hadoop 插件。

我们现在可以看到 vRO 如何集成 BDE 插件并运行工作流：

1. 登录到 vRO 配置页面 https://xx.xxx.x.xx:8283/config_general/General.action：

1. 在左侧点击插件选项卡：

1. 滚动到页面底部并点击放大镜。找到放大镜并选择所需的插件文件：

1. 点击上传并安装按钮。

2. 接受许可协议。

这是 VMware vRealize Orchestrator 控制台，通过它可以管理任务：

1. 点击启动选项以重启 vRO 服务和重启 vRO 配置服务器。

2. 登录到 vRO 客户端，然后在“运行”下选择工作流。

3. 在库中，你应该能看到 Hadoop 集群作为服务。

4. 展开 Hadoop 集群作为服务，然后展开配置。右键单击配置 Serengeti 主机并点击启动工作流：

1. 将 Serengeti 管理服务器的 URL 输入为 https://xx.xxx.x.xx:8443/serengeti。

2. 以 UPN 格式输入 vCenter 管理员的用户名（例如，user@domain.com）。输入管理员的密码并点击提交：

   • Serengeti 主机的连接 url：例如，`https://10103.3.18:8443/serengeti`

   • vCenter Server 用户名：例如，vrasvcqa@qvcdev.qvc.net：

1. 我们遇到了关于导入证书的问题。在表单的最后页，从下拉菜单中选择安装证书…：

1. 点击下一步，然后点击提交：

Serengeti 主机现在已完全配置。

我们可以使用 VRO 来配置集群，因为工作流“配置 Serengeti 主机”中硬编码了 30 秒的宿主连接和操作超时值。

以下截图显示了工作流创建设置；用户可以根据他们的需求创建不同的工作流：

我们必须在 vRA 的 BDE 集群蓝图中选择网络或数据存储资源选项。在 Web 客户端侧应该有一个下拉选项来选择特定的 BDE 资源。这需要在 vRA 蓝图表单中进行定制。配置 Serengeti 主机以添加连接和操作的超时值。我们还有一个从 vSphere Web 控制台选择 BDE 集群大小（小型、中型、大型）的选项。这需要在 vRA 蓝图侧进行定制。

开源软件

与传统的专有解决方案相比，组织需要具备很高的技能集来接受开源，因为从头开始构建一个具有所有集成支持的解决方案与利用经过验证的供应商解决方案之间存在很大差异。对于许多企业来说，这些挑战过于艰巨，削弱了开源选择对他们的价值。商业策略、投资以及许多其他因素都会发挥作用。在这些情况下，企业发现，商业支持的开放源代码解决方案或专有解决方案更好地支持他们的战略。客户将数字和在线销售渠道作为其市场进入策略的支柱，开发符合其业务用例独特需求的 OpenStack 的专有实现。

客户已经投入了时间、人才和资源来优化 OpenStack 以满足他们的特定需求。一家主要体育零售商选择了基于开源的解决方案，而不是实施商业版的 OpenStack。VMware Integrated OpenStack 帮助客户节省时间和资源，将他们的技术人才投入到优化其战略中面向客户的输出部分。开源无疑是当今每个公司软件组合中的战略部分。虽然开源软件有其优势，但生产就绪并不是其最突出的属性。还有很多工作要做：将代码达到商业销售产品的标准不是一项微不足道的投资，并且需要专业技能。

从选择到测试、集成和安全，都需要一些组装。对于大多数企业来说，这不是他们想要的投资；他们更愿意投资于他们的核心能力，而不是成为开源项目单一实现的专家。这就是商业提供商，如 VMware，介入提供企业可以依赖的实用、实用的开源软件的地方。

Open vSwitch（OVS）是 VMware 贡献的另一个例子。该代码已转让给 Linux 基金会协作项目，以获得 VMware 和社区持续的支持，并继续发挥积极作用，因为 VMware 工程师负责 OVS 活跃提交的 70%以上。这些贡献被视为个人贡献，并且整个行业的社区支持持续增长。VMware 正在通过 EdgeX 和网络功能虚拟化（NFV）在物联网空间进行战略投资，并在开放网络自动化平台（ONAP）方面拥有专业知识。

清晰性是内部创建软件并选择将其开源以惠及更广泛社区的绝佳例子。清晰性是一个 UX/UI 设计框架，因为它帮助开发者和设计师处理应用程序的视觉方面。清晰性是在 VMware 内部开发的，以满足产品的 UI/UX 需求，但它不依赖于 VMware 产品的工作或提供价值。它可以应用于几乎任何环境，因此选择将其开源。清晰性因其活跃的社区、下载次数超过 10 万次以及主页上* 100 万次的浏览量而迅速发展。我们的开源项目还包括帮助开发者提高效率的工具和套件。

挑战式握手认证协议（CHAP）是一个分析未配置的 ELF 核心文件以查找泄漏、内存增长和损坏的工具。

VMware 产品基于开源，我们支持并为其做出贡献，但我们不是开源软件公司。VMware 软件，无论是专有软件还是基于开源，都是生产就绪的：它得到全面支持、全面测试和优化——它是安全的，并准备好部署。

考虑包含资本支出（CapEx）和运营支出（OpEx）的解决方案

我们可以看到，使用开源解决方案，资本支出成本随着许可成本的潜在减少而降低，而运营支出成本则随着

部署和维护开源解决方案所需的支持和熟练的技术人力。我们看到资本支出在流行度上上升，这反映了商业现成软件解决方案的许可和支持合同成本，而运营支出则下降，因为修补、升级、增强和保障软件的负担落在供应商身上，而不是企业 IT 部门。

这不是一对一的权衡，而是你必须在整个企业中考虑的事情；这不是一个短期决定；它具有长期、结构和战略影响。如果你在招聘或留住员工方面遇到困难，转向依赖你的知识产权和技术专长来使解决方案工作的开源解决方案可能会使你处于非常脆弱的地位。你可能会被咨询公司或外包公司“牵着鼻子走”，他们承诺在生产操作过程中“手把手”地帮助你。这些成本很少随着时间的推移而降低。另一个要考虑的选项是混合解决方案：商业支持的开放源代码发行版或开源项目的商业化版本。另一个要探索的选项是双层选项：一些公司提供“社区版”，这是他们免费提供的开源项目，并提供第二个版本，通常标记为“企业版”，这是一个销售产品，提供更健壮的软件版本，并得到全面支持。我们可以利用开源来构建我们的策略，并为业务做出正确的决策。因此，从基础开始，我们必须知道我们的应用程序开发人员或 IT 人员在哪里以及如何利用开源，并了解他们选择背后的决策，包括好处以及差距。

当我们的团队开始参与开源项目时，给他们提供指南，让他们对自己的贡献有信心。我们应该有一个单一的联系点，用于关于知识产权、许可类型和合规性以及最佳实践的问题，并首先考虑安全选项。如果我们想创建一个新的开源项目或更深入地参与现有的项目，务必了解战略意图。这是一个长期承诺，需要人才和时间投资，否则我们的努力将徒劳无功，因为它们耗时、分散注意力、花钱，还可能令人烦恼。我们必须评估开源解决方案和专有、供应商支持并销售解决方案之间的选择，因为这是一个战略选择，而不仅仅是购买决定。我们需要权衡资本支出和运营支出的利弊，并仔细评估我们的长期承诺和招聘员工的能力。我们可以讨论以了解成本和好处，以及技术曲线。

虚拟化 Hadoop 的好处

虚拟化 Hadoop 的好处如下：

• 按需配置：根据定义的政策自动化集群部署过程

• 持续可用性：vSphere 内置的 HA 保护保护了单点故障

• 灵活性：资源（CPU、内存、网络和存储）可以根据您的需求按需扩展和缩减

• 多租户环境：根据安全合规性，运行 Hadoop 的不同租户可以在共享基础设施中隔离

用例 - 安全和配置隔离

Hadoop 的认证和授权模型较弱。敏感数据难以保护。它有多个 MapReduce 工作负载，用于生产批处理分析、即席分析和实验任务，不同作业有不同的服务级别协议（SLA）。

我们需要考虑以下因素：

• 在合理的地方，将 HDFS 合并以最小化数据重复

• 高优先级作业获得更多资源，以确保它们按时完成

• 每种类型的作业都可以在任何时候获得尽可能多的资源

• 避免 CPU 和内存争用，以便更好地利用资源，按时完成工作

我们的目的是通过一个大型的共享基础设施来集成 Hadoop 工作负载和其他工作负载。Hadoop MapReduce 框架使用 HDFS 作为底层文件系统来处理大量数据，并使用自己的存储机制。我们还有其他技术，如 HBase 和 Pivotal。

案例研究 - 为一家主要媒体提供商自动化应用程序交付

以下是一些挑战：

• 客户要求任何应用程序都必须能够部署到任意数量的后端基础设施，跨越多个私有云

• 一个特定的应用程序（占地面积超过 10,000 台服务器）需要更好的配置程序和工具，以确保达到规定的目标

• 客户当前的配置模型需要彻底改革，因为启动时间长达数周甚至数月，主要是由手动程序组成

以下是解决方案：

• 通过业务流程管理（BPM）平台/工作流引擎和底层 Java 服务，实现了一个基于版本控制、软件定义的基础设施自动化工作流程方法

• 利用 Puppet 架构进行构建流程和打包，以及面包房工作流程进行镜像

• 通过基于 Ruby 的控制台和报告用户界面（UX）提供操作洞察

• 将 Jira 集成到配置工作流程中，将使交付更加易于使用，因为可以使用熟悉的工具

• 配置了应用程序服务器以及所需的 Memcached 和相关实例数量

• 新系统验证了新配置的基础设施，自动清理任何故障，并自动切换路由规则以提供新基础设施

• 为客户提供必要的工具和模式，以实现可重复操作

• 创建了更好的构建程序和流程，从而产生了更稳定的基础设施变更

• 目标基础设施的部署时间从数周/数月减少到 270 台服务器的 90 分钟

摘要

对于许多企业来说，Hadoop 仍然相当新颖，不同的公司在 Hadoop 采用之旅中处于不同的阶段。与几位客户合作后，很明显，根据客户所处的阶段，存在不同的 Hadoop 用例和需求。虚拟化可以帮助解决每个阶段的关键需求。公司内的不同部门可以使用多个 Hadoop 集群。

在公司中管理多个部门的不同集群并保持它们都运行良好是很困难的。我们正在运行多个用例，包括数据挖掘、推荐引擎，以及为我们的在线服务，我们有一个共享的数据集，而不是到处都是重复的数据。我们现在管理的是一个集群，而不是多个集群。

在下一章中，我们将学*如何通过为开发者提供访问传统和现代应用程序开发框架和资源（包括容器服务和开放 API）的权限，在共同的 vSphere 平台上支持云原生应用程序开发。这使基于微服务的架构能够实现更快和更频繁的开发，同时不牺牲安全性、可靠性和治理。

进一步阅读

查阅以下资源，以获取本章涵盖主题的更多信息：

• Adobe 在 VMware vSphere 上部署 Hadoop 作为服务，请参阅www.vmware.com/files/pdf/products/vsphere/VMware-vSphere-Adobe-Deploys-HAAS-CS.pdf

• 在大型基础设施中虚拟化 Hadoop，EMC 技术白皮书，请参阅community.emc.com/docs/DOC-41473

• 在高性能服务器上使用 VMware vSphere 6 虚拟化 Hadoop 的性能，请参阅www.vmware.com/resources/techresources/10452

• 在 vSphere 上虚拟化 Hadoop 性能的基准测试案例研究，请参阅www.vmware.com/resources/techresources/10222

• 事务处理委员会—TPCx-HS 基准测试结果（Dell 提交的 Cloudera 在 VMware 上的性能），请参阅www.tpc.org/tpcx-hs/results/tpcxhs_results.asp

• ESG 实验室评论：VCE vBlock/systems 与 EMC Isilon 用于企业 Hadoop，请参阅www.esg-global.com/lab-reports/esg-lab-review-vce-vblock-systems-with-emc-isilon-for-enterprise-hadoop/

• VMware BDE 文档站点：vSphere 大数据扩展 (BDE)，请参阅www.vmware.com/support/pubs/vsphere-big-data-extensions-pubs.html

• VMware vSphere 大数据扩展—管理员和用户指南以及命令行界面用户指南，请参阅www.vmware.com/support/pubs/vsphere-big-data-extensions-pubs.html

• 关于 BDE 版本 2.1 的博客文章，请参阅blogs.vmware.com/vsphere/2014/10/whats-new-vsphere-big-data-extensions-version-2-1.html

• VMware 大数据扩展（BDE）社区讨论，请参阅communities.vmware.com/message/2308400

• 使用 VMware vSphere 大数据扩展进行 Apache Hadoop 存储配置，请参阅www.vmware.com/files/pdf/VMware-vSphere-BDE-Storage-Provisioning.pdf

• 在 VMware vSphere 5 上使用 Hadoop 虚拟化扩展，请参阅www.vmware.com/files/pdf/Hadoop-Virtualization-Extensions-on-VMware-vSphere-5.pdf

• 使用大数据扩展在 vSphere 上进行容器编排，请参阅labs.vmware.com/flings/big-data-extensions-for-vsphere-standard-edition

第十三章：云应用扩展

本章将指导您了解如何通过为开发者提供访问传统、云原生和现代应用开发框架和资源，包括生产级容器服务和开放 API，来支持下一代云应用开发。这些将在共同的 vSphere 平台上使用，并将支持与云原生和容器化应用并行运行的遗留或传统应用，在整个虚拟化环境中。

你将学*如何通过定义参数和假设情景来优化资源以获得最大产出。这些将考虑未来的可扩展性，以便我们可以在不同的云环境中配置和自动扩展参数。

在本章中，我们将涵盖以下主题：

• 云原生应用

• 基于 vSphere 的Pivotal 容器服务（PKS）

技术要求

您可以从cloud.vmware.com/vmware-enterprise-pks/resources下载 VMware Enterprise PKS。

云原生应用

由于今天的动态商业目标，数字技术总是在变化。通过移动、社交网络、可穿戴设备、联网汽车等一切事物都连接在一起，并且它们都在影响着我们今天的行为和与技术互动的方式。由于这种技术创新，客户对体验产品和服务的要求更加创新、灵活和快速。

让我们看看相互独立运作的系统、责任和技能集。我们正处于数字化转型中，需要跨各个段落的这些操作。数字化转型在很多环境中重新设计组织结构，以便它们能够协作。技术可以提升性能，并使组织在全球范围内扩大其影响力。

云原生应用具有四个特征：

• 云原生应用由微服务组成：云原生应用采用微服务架构，其中每个应用程序都是一组小型服务，可以独立于彼此运行。微服务通常由个人开发团队拥有，这些团队在自己的时间表下开发、部署、扩展和升级他们的服务。

• 云原生应用打包在容器中：容器为微服务提供隔离的上下文。它们高度可访问、可扩展，易于从一个环境便携到另一个环境，创建或拆除速度快，这使得它们非常适合构建和运行由微服务组成的应用程序。

• 云原生应用运行在持续交付模型中：软件开发人员和 IT 运维团队在这个模型下协作，以便在软件准备就绪时立即构建、测试和发布软件更新，而不会影响最终用户或其他团队的开发人员。

• 云原生应用程序在云中动态管理：它们通常在提供易于扩展和硬件解耦的现代云原生平台上构建和运行，这有助于应用程序的编排、管理和自动化。

使用容器进行自动化

对于已经大量部署 VMware 自动化工具的客户来说，可以轻松推动敏捷性和简化 IT 服务的消费。VMware 将帮助客户提供应用程序和容器服务。这个平台将 BOSH（自动扩展、自我修复、负载均衡等）的好处扩展到容器即服务（CaaS）解决方案（PKS）。BOSH 是一个开源工具，有助于分布式系统的部署和生命周期管理。PKS 是唯一能够提供本地完全管理的 Kubernetes 集群以及公共基础设施即服务（IaaS）的 CaaS 解决方案。这个平台还将包括函数即服务（FaaS）。这将允许组织通过在一个平台上提供应用程序部署和运行时结构来确保其抽象规划的安全性，无论 IaaS 如何。因此，我们必须与负责应用程序合理化和与业务和技术需求相关的后续迁移的各个团队进行详细规划。

Pivotal Cloud Foundry（PCF）包括Pivotal 应用程序服务（PAS）和 PKS 作为关键组件。PAS 是用于部署和运行现代应用程序的云原生平台。PKS 使客户和服务提供商能够在 VMware SDDC 和其他公共云环境中提供生产就绪的 Kubernetes。

例如，如果我们有一个在容器中运行的 10 个应用程序的系统，那么这 10 个应用程序将会有 10 个隔离的用户空间实例。想象一下，如果两个应用程序安装在同一操作系统上，但每个都需要该文件的不同版本。我们可以通过使用一个公共共享库文件来管理这种条件。容器（更具体地说，Linux 容器）已经存在了一段时间，像 Oracle、HP 和 IBM 这样的公司已经使用容器几十年了。然而，Docker 在用户中变得更加流行。

部署支持命名空间和资源限制的应用程序的易于使用的 API 和 CLI 工具简化了部署和管理容器的复杂性。容器是一个运行中的镜像实例，该镜像运行容器。我们需要下载一个镜像来使用它。镜像是一个分层文件系统，其中每一层都有自己的文件系统。

当你想进行更改时，没有必要打开一个单一的大型单体应用程序并将新更改塞进去。如果我们必须进行更改，我们只需将它们添加到一个新层即可。

容器正在对操作系统做的是虚拟机对服务器硬件所做的事情。运行和操作容器所需的工具和组织流程通常没有明确定义。VMware 和 Pivotal 处于独特的位置，能够解决这些新的挑战并成为既得利益者。容器通过限制我们需要在操作系统上安装的应用程序依赖项的数量来虚拟化操作系统。

容器的用例

以下是一些容器的用例：

• 开发者沙盒的需求：开发者经常希望访问运行特定框架的一组机器，以构建或快速测试和验证他们的应用程序。配置这样的环境是耗时的，通常涉及工单和审批。因此，开发者要么请求虚拟机并根据他们的需求进行定制，创建雪花部署，要么他们永远不会放弃这些资源，因为他们担心获得新的资源可能是一个繁琐的过程。

• 应用程序重新打包：客户可以将现有的应用程序打包为容器。您不需要重构代码或更改架构。虽然这构成了客户容器化旅程中的第一个逻辑步骤，但它使客户能够获得某些好处。修补和维护应用程序是一个主要的好处，其中更新可以仅限于镜像的各个单独层。这确保了其他层保持完整，减少了可能出现的错误和配置问题。

• 可移植性：将应用程序打包为容器可以使其具有可移植性。由于容器镜像不仅打包了应用程序代码，还包括了所有依赖项，因此可以保证在任何地方都能运行。现在我们能够将这个镜像从开发者的笔记本电脑移动到您的测试/开发或生产环境，而无需投入时间和资源来确保目标环境与开发环境（或反之）完全一致。

容器面临的挑战

我们专注于使开发者的代码能够实例化开发者所需的所有资源，即使是对于遗留系统，以便在瀑布方法中提供高水平的自动化，并使客户能够自助满足其资源需求。

传统模型使用传统的应用程序架构、工具和流程，在云交付模型中，开发者需要提交工单以获取资源。资源通过自助服务提供。云原生应用程序通过代码发起这些请求，并提供基础设施即代码（IaC）服务。

代码取代了服务票证，API 在其中扮演着关键角色。通过提供帮助运行容器的 API，如 OpenStack、PCF 等，可以使用自动化的 VMware SDDC 工具实现开发者就绪的基础设施。由于开发者获得了所有的好处，因此可以从现有的运营模式中管理容器。这是因为 IT 必须以一致的方式管理底层资源。

在微服务架构中，全局一致的基础设施层具有优势，因为每个服务定义了其与其他微服务的关系。如果底层网络复杂且没有可见性，则可能会破坏这种关系。网络应该完全开放以避免这个问题。Pivotal 重视 VMware NSX 和开发者就绪基础设施具有相同的代码，该代码定义了微服务之间的关系并实例化了安全的微分段网络连接。即使是无服务器架构也可能出现内部服务器错误消息。

PKS 在 vSphere 上

vSphere 集群组是一组具有共同计算实体的 ESXi 主机；当在集群级别激活 vSphere HA 和 DRS 时，每个 vSphere 集群有 2 到 64 个主机。在 vSphere 集群实例下创建资源池，vCenter 能够管理多个 vSphere 集群实例，因为没有对 vSphere 集群数量的硬性限制。我们可以创建不同类型的 vSphere 集群，如管理集群、计算集群和边缘集群，因为 PKS 完全利用了 vSphere 集群结构。

在典型的 PKS 部署中，以下 vSphere 集群是推荐的：

• 管理集群：

  • 托管组件：vCenter、NSX 管理器和控制器虚拟机

  • vSphere HA 和 DRS 已启用

  • ESXi 主机需要为 NSX 准备，因为托管虚拟机上强制执行微分段

• 计算集群：

  • 托管组件：Kubernetes (K8s) 集群节点虚拟机

  • 应启用 vSphere HA 和 DRS，因为 BOSH 将检查 DRS 是否已开启

  • ESXi 主机需要为 NSX 准备

• 边缘集群：

  • 托管组件：NSX 边缘节点虚拟机

  • vSphere HA 和 DRS 已启用

  • ESXi 主机不需要为 NSX 准备

PKS 管理平面可以位于管理集群或计算集群，具体取决于所选的设计场景。PKS 管理平面虚拟机包括 Ops Manager、BOSH、PKS 控制平面和 Harbor。

PKS 数据平面（或计算平面）将仅位于计算集群中。每个 K8s 集群允许最多三个主节点和 50 个工作节点，并且可以在同一个 PKS 环境中创建多个 K8s 集群。

K8s 主节点也托管 etcd 组件。vSphere 计算集群上必须启用 vSphere DRS 和 HA。vSphere DRS 自动化必须设置为部分自动化或完全自动化。vSphere HA 设置为主机故障 = 重启虚拟机。

以下是对 PKS 组件的计算和存储要求的说明：

PKS 组件	CPU	RAM (GB)	存储 (GB)
Ops Manager	1	8	HD1: 160
PKS 控制平面虚拟机	2	8	HD1: 3HD2: 16HD3: 10
BOSH	2	8	HD1: 3HD2: 50HD3: 50
Harbor	2	8	HD1: 3HD2: 64HD3: 30
K8s 主节点	每个 PKS 计划可配置	每个 PKS 计划可配置	临时磁盘：8 到 256 GB 持久磁盘：1 GB 到 32 TB（每个 PKS 计划可配置）
K8s 工作节点	每个 PKS 计划可配置	每个 PKS 计划可配置	临时磁盘：8 到 256 GB 持久磁盘：1 GB 到 32 TB（每个 PKS 计划可配置）

PKS 可用区

PKS 支持可用区（AZ）的概念，即 AZ = vSphere 集群 + 资源池。可用区决定了由 BOSH/PKS 创建的虚拟机放置到相应的 vSphere 集群/资源池。

有两种类型的可用区：

• 管理可用区：用于 BOSH、PKS 控制平面和 Harbor 虚拟机

• 计算可用区：用于 K8s 主节点和工作节点虚拟机

PKS 支持多个计算可用区，并且每个 PKS 计划最多支持三个不同的可用区。每个 K8s 主节点（最多三个）将落在单独的一个可用区。K8s 工作节点将在三个区域之间分配。

允许三个 PKS 计划（总共九个不同的计算区域）。每个 PKS 计划可以使用相同的三个区域或完全不同的三个可用区。可用区通常用于设置虚拟机相对于不同位置的本地域；或者，我们可以说 AZ = 物理机架（或房间）。

以下是 PKS 设计拓扑：

• 物理拓扑（与 vSphere 集成）：可以通过 PKS/NSX-T 集成部署多种拓扑。

• 管理集群中的 PKS 管理平面：多计算集群：

  • PKS 管理平面托管在管理集群中，并连接到 DVS 虚拟交换机

  • 多个计算集群，以支持 K8s 集群节点

  • 每个可用区映射到不同的 vSphere 集群（可用区与 vSphere 集群之间 1:1 映射）。

  • AZ 可以代表一个物理位置：每个计算集群可以位于专用机架或房间

• 单个计算集群的管理集群中的 PKS 管理平面：

  • PKS 管理平面托管在管理集群中，并连接到 DVS 虚拟交换机

  • 单个计算集群以支持 K8s 集群节点

  • 每个可用区映射到一个唯一的 vSphere 集群（可用区与 vSphere 集群之间 1:1 映射）

  • 可用区可以用来限制每个 PKS 计划的 CPU/内存

• 多计算集群中的 PKS 管理平面：

  • PKS 管理平面托管在计算集群中，并连接到 NSX-T 逻辑交换机

  • 多个计算集群，以支持 K8s 集群节点

  • 每个可用区映射到不同的 vSphere 集群（可用区与 vSphere 集群之间 1:1 映射）

  • 一个可用区可以代表一个物理位置：每个计算集群可以位于专用机架或房间

• 计算集群中的 PKS 管理平面，或单个计算集群：

  • PKS 管理平面托管在计算集群中，并连接到 NSX-T 逻辑交换机

  • 单个计算集群，以支持 K8s 集群节点

  • 每个可用区映射到一个唯一的 vSphere 集群/不同的资源池：

  • 可用区可以用于每个 PKS 计划的 CPU/内存限制

• PKS 可用区（单/多个计算和管理集群）设计模型：

  • 具有单个 vSphere 计算集群的 PKS 可用区：默认情况下，无法保证 K8s 主节点落在不同的 ESXi 主机上。一种解决方案是在 vSphere 计算集群上创建一个 DRS 亲和规则。

  • 类型：独立的虚拟机。

  • 成员：所有 K8s 主节点虚拟机。

  • vSphere 集群必须至少有三个 ESXi 主机（这是 vSAN 的先决条件）。然而，为了防止单个主机故障（并确保 DRS 亲和规则能够正常工作），建议在集群中启动四个 ESXi 主机。

  • NSX-T 2.2 支持在 N-VDS 上的所有类型流量。这意味着计算集群中的 ESXi 主机可以从两个物理网卡开始。

生产环境的最低 vSphere 集群配置如下：

• 管理集群：

  • 非-vSAN: 最小主机数：两个

  • vSAN: 最小主机数：三个（为保证 vSAN 对象的数据保护，必须有两个副本和一个见证）

• 计算集群：

  • 单个计算集群拓扑：

    • 非-vSAN: 最小主机数：三个（通过使用 DRS 亲和规则保证每个 ESXi 主机有一个 K8s 主节点虚拟机）

    • vSAN: 最小主机数：三个（为保证 vSAN 对象的数据保护，必须有两个副本和一个见证）

  • 多个计算集群拓扑：

    • 非-vSAN: 最小主机数：每个可用区两个，总共三个可用区（K8s 主节点实例化在不同的计算集群中。每个计算集群与一个可用区一一对应）

    • vSAN: 最小主机数：每个可用区三个，总共三个可用区（为保证 vSAN 对象的数据保护，必须使用两个副本和一个见证）

• 边缘集群：

  • 非-vSAN: 最小主机数：两个。

  • vSAN: 最小主机数：三个（为保证 vSAN 对象的数据保护，必须使用两个副本和一个见证。）注意：如果需要减少启动 ESXi 主机的数量，可以将边缘集群与计算集群（甚至管理集群）合并。

以下表格提供了关于 PKS/NSX-T 网络的信息：

网络	描述	CIDR
PKS 管理网络

• 此网络托管 Ops Manager、BOSH、PKS 控制平面和 Harbor

• 如果需要，可以与 vCenter、NSX-T 管理和控制平面共置

• PKS 管理网络是可路由或不可路由的，这取决于 NO-NAT 或 NAT 拓扑

192.168.1.0/28（例如）CIDR，/28 是一个良好的起点。

节点 IP 块

• 此块将被分割以创建一个网络，该网络将托管 K8s 集群节点虚拟机

• 每个 K8s 集群将被分配一个 /24 的块

• 节点 IP 块是可路由或不可路由的，这取决于 NO-NAT 或 NAT 拓扑

取决于 NAT 或 NO-NAT 拓扑。172.23.0.0/16（例如）

Pods IP 块

• 此块将被分割以创建一个网络，该网络将托管属于同一 K8s 命名空间的 K8s Pods

• 每个 k8s 命名空间将分配到 /24 块的部分

• Pods IP 块始终不可路由

172.16.0.0/16（例如）

浮动 IP 池

• 此池将用于以下两个目的：

  • T0 上每个 K8s 命名空间的 SNAT 规则（用于 Pods 网络）

  • LB 虚拟服务器 IP 分配

• 浮动 IP 池始终可路由

192.168.20.2-192.168.20.254（例如）

节点 IP 块的 CIDR：

• 在可路由场景中必须是唯一的（NO-NAT 拓扑）

• 在不可路由场景中可以重复（NAT 拓扑）

在所有情况下，172.17.0.0/16CIDR 都不得使用，因为 K8s 工作节点上的 Docker 正在使用该子网。

如果与 Harbor 部署 PKS，则必须不使用以下 CIDR，因为 Harbor 正在使用它为其内部 Docker 桥接器：

 172.18.0.0/16 ;172.19.0.0/16 ;172.20.0.0/16 ;172.21.0.0/16 ;172.22.0.0/16

每个 K8s 集群使用以下 IP 块用于 Kubernetes 服务，因此请避免将其用于节点 IP 块：10.100.200.0/24。

PKS/NSX-T 逻辑拓扑

当与 NSX-T 集成时，PKS 支持两种类型的拓扑。NAT 和 NO-NAT 拓扑选择在 PKS 瓦片 | 网络部分完成。NAT 拓扑是默认的，但您可以取消选中 NAT 模式以使用 NO-NAT 拓扑。NAT 和 NO-NAT 术语基本上适用于 PKS 管理网络和 K8s 集群节点网络（即是否使用可路由子网）。无论 NAT 还是 NO-NAT 拓扑，访问 K8s API 都使用相同的程序。

在分配给 K8s 集群的 NSX-T LB 实例上创建的虚拟服务器用于以下目的：

• 从 PKS 浮动 IP 池中提取一个 IP（此处为 1x.x0.1x.1xx），端口号为 8443

• pks cluster <cluster name> 命令的输出显示了相同的 IP 地址

以下是不同 NAT 拓扑的目标：

• NAT 拓扑：对于在他们的数据中心拥有有限的可路由 IP 地址并且希望使用 concourse 管道（例如）自动化 PKS 部署的客户

• NO-NAT 拓扑：对于避免 NAT（NAT 会破坏完整路径可见性并且拥有大量可路由 IP 地址资源）的客户

不同配置的使用案例

以下是与不同配置相关的使用案例：

• 从企业网络访问 PKS 管理平面组件（Ops Manager、BOSH、PKS 控制平面 VM、Harbor）：

  • NO-NAT 拓扑：无需采取任何行动，因为这些组件使用可路由 IP 地址

  • NAT 拓扑：用户需要在 T0 上创建 DNAT 规则

• 访问 K8s API（例如使用 kubectl CLI）：

  • NO-NAT 拓扑：1 个虚拟服务器（在专用于 K8s 集群的 NSX-T LB 实例上）自动创建，使用 1 个可路由 IP 从 PKS 浮动 IP 块

  • NAT 拓扑：用户需要指向此 IP 以访问 K8s API

• 使用 PKS 浮动 IP 块中的一个可路由 IP 地址，自动创建一个虚拟服务器（在专门用于 K8s 集群的 NSX-T 负载均衡器实例上）：

  • 无 NAT 拓扑结构：用户需要指向此 IP 以访问 K8s API

  • NAT 拓扑结构：用户需要访问 K8s 节点 VM（例如，BOSH SSH）

• 使用可路由 IP 地址的组件：

  • 无 NAT 拓扑结构：用户需要 SSH 到 Ops Manager 以执行针对 K8s 节点 VM 的 BOSH 命令

  • NAT 拓扑结构：一种替代方案是在同一子网上安装一个跳转盒服务器，而不是 PKS 管理平面组件

• 使用 K8s 节点 VM 访问公司网络（或互联网）：

  • 无 NAT 拓扑结构：不需要采取任何行动，因为这些组件使用可路由 IP 地址

  • NAT 拓扑结构：PKS 会自动为每个 K8s 集群在 T0 上创建一个 SNAT 规则，使用 PKS 浮动 IP 池中的一个 IP 地址

PKS 和 NSX-T 边缘节点和边缘集群

PKS 仅支持大型尺寸的 NSX-T 边缘节点 VM 配置。PKS 仅支持一个 T0（8 vCPU，16 GB RAM）的 Edge Cluster 实例。T0 路由器必须配置在活动/备用模式，因为 PKS 将在那里应用 SNAT 规则。NSX-T 边缘集群可以包含多达八个边缘传输节点（TN）。您可以在边缘集群中添加新的边缘节点（最多八个）以增加整体容量（例如 LB）并为 NSX-T 边缘集群提供可伸缩性。您可以使用两个不同的边缘节点为 T0 上行链路 IP 地址（总共两个 IP 地址）提供 NSX-T T0 在边缘集群中的高可用性。我们应该在 T0 上启用 HA VIP，以确保其始终处于运行状态，即使一个 T0 上行链路出现故障。物理路由器将仅与 T0 HA VIP 交互操作。

以下列出了 NSX-T 和负载均衡器的缩放数字：

	小型 LB	中型 LB	大型 LB	池成员
NSX-T 版本	2.1	2.2	2.1	2.2
边缘 VM：小型	-	-	-	-
边缘 VM：中型	1	1	-	-
边缘 VM：大型	4	40	1	1
裸金属边缘	100	750	10	100

PKS 和 NSX-T 通信

多个 PKS 组件需要与 NSX-T 管理器通信。需要一个使用 NSX-T 超级用户主体身份证书作为认证机制的 PKS 控制平面 VM，以创建每个 K8s 集群节点网络的 T1/LS 以及每个 K8s 集群的 LB 实例。

BOSH 使用凭证作为认证机制，为 VM 的所有逻辑端口添加特殊的 BOSH ID 标签和 NCP pod。它使用 NSX-T 超级用户主体身份证书作为认证机制，为每个命名空间创建 T1/LS，为每个命名空间在 T0 上创建 SNAT 规则，并为每个类型的 LB K8s 服务创建 LB 虚拟服务器。

以下是为每个 K8s 集群创建的 NSX-T 对象的列表。

当创建一个新的 K8s 集群时，以下 NSX-T 对象默认创建：

• NSX-T LS：

  • 为 K8s 主节点和工作节点创建一个 LS

  • 为每个 K8s 命名空间创建一个 LS，即 kube-public、kube-system 和 pks-infrastructure

  • 一个与 K8s 集群关联的 NSX-T 负载均衡器 LS

• NSX-T T1：

  • 为 K8s 主节点和工作节点创建一个 T1（称为 cluster-router）

  • 为每个 K8s 命名空间（默认，kube-public，kube-system 和 pks-infrastructure）创建一个 T1

  • 为与 K8s 集群关联的 NSX-T 负载均衡器创建一个 T1

• NSX-T 负载均衡器：

  • 一个包含以下对象的 NSX-T 负载均衡器小实例：

    • 一个虚拟服务器用于访问 K8s 控制平面 API（端口 8443）

    • 包含三个 K8s 主节点的服务器池

    • 为入口控制器创建一个虚拟服务器（HTTP）

    • 为入口控制器创建一个虚拟服务器（HTTPS）

    • 每个虚拟服务器分配一个从 PKS 浮动 IP 池派生的 IP 地址

当创建一个新的 K8s 集群时，以下 NSX-T 对象默认创建：

• NSX-T DDI/IPAM：从节点 IP 块中提取并分配一个/24 子网给 K8s 主节点和工作节点。

• NSX-T DDI/IPAM：从 PODs IP 块中提取并分配一个/24 子网给每个 K8s 命名空间（默认，kube-public，kube-system 和 pks-infrastructure）。

  • NSX-T T0 路由器：

    • 为每个 K8s 命名空间（默认，kube-public，kube-system，pks-infrastructure）创建一个 SNAT 规则，使用浮动 IP 池中的一个 IP 作为翻译的 IP 地址。

    • 为每个 K8s 集群（如果使用 NAT 拓扑）创建一个 SNAT 规则，使用浮动 IP 池中的一个 IP 作为翻译的 IP 地址。K8s 集群子网是从节点 IP 块中派生的，使用/24 子网掩码。

  • NSX-T DFW：

    • 为 kubernetes-dashboard 创建一个 DFW 规则：源=K8s 工作节点（托管仪表板 POD）/ 目标=仪表板 POD IP/端口：TCP/8443/操作：允许

    • 为 kube-dns 创建一个 DFW 规则：源=K8s 工作节点（托管 DNS POD）/ 目标 = DNS POD IP/端口：TCP/8081 和 TCP/10054/操作：允许

K8s 集群节点 VM 的存储

您可以通过使用持久卷（PV）为 K8s POD 提供存储。可以通过使用vCP（代表云提供商）插件将 PV 映射到 vSphere 上的虚拟机磁盘（VMDK）文件。然后，将 VMDK 文件作为磁盘附加到工作节点 VM。然后我们可以从该磁盘挂载卷。

数据存储

以下是一个关于数据存储的信息表：

部署拓扑/存储技术	vSAN 数据存储	VMFS 通过 NFS/iSCSI/FC 数据存储
单个 vSphere 计算集群（单个可用区，或使用 RPs 时的多个可用区）具有本地数据存储

• 静态 PV 配置：是

• 动态 PV 配置：是

|

• 静态 PV 配置：是

• 动态 PV 配置：是

|

多个 vSphere 计算集群（多个可用区）具有本地数据存储

• 静态 PV 配置：否*

• 动态 PV 提供程序：否*

|

• 静态 PV 提供程序：否*

• 动态 PV 提供程序：否*

|

多个 vSphere 计算集群（多个 AZs）共享所有 vSphere 计算集群的数据存储（s）

• N/A

• vSAN 不支持跨 vSphere 集群的共享数据存储

|

• 静态 PV 提供程序：是

• 动态 PV 提供程序：是

|

以下是为静态 PV 提供的步骤：

1. 手动创建 VMDK 文件

2. 创建一个引用上述 VMDK 文件的 PV

3. 创建 PVC

4. 通过引用 PVC 来部署有状态的 POD 或 StatefulSets

以下是为动态 PV 提供程序提供的步骤：

1. 创建 PVC（vCP K8s 存储插件；hatchway 将自动创建 PV 和 VMDK 文件）

2. 使用 PVC 引用部署有状态的 POD 或 StatefulSets

以下是一些关于 PKS/NSX-T 的 vSAN 考虑事项：

• 使用 vSAN，vSphere 集群必须从至少三个 ESXi 主机开始，以确保数据保护（在这种情况下，对于 RAID1，容错设置为 1）

• PKS 的 AZ 无法与 vSAN 故障域进行映射

• 目前支持带有 vSAN 的单个计算集群的 PKS（所有 ESXi 主机都位于同一站点）

• 注意: 目前为止，带有 vSAN 拉伸集群的 PKS 不是一个受支持的配置（因为没有将 AZs 与 vSAN 故障域进行映射）

• 带有多个计算集群的 PKS 在仅使用 vSAN 数据存储的情况下不是一个受支持的配置

• 主节点和工作节点可以跨不同的 ESXi 集群创建（BOSH 瓦片允许您为虚拟机指定多个持久和临时数据存储）

• 仅为单个 vSAN 数据存储创建 PV VMDK 磁盘（并且不会自动在不同 vSAN 数据存储之间执行复制）

数据中心维护独立的 PKS 实例、NSX 部署、Kubernetes（K8s）集群和 vSphere 基础设施。一个全局服务器负载均衡器（GSLB），通过第三方提供，监控站点 K8s 集群 API 和 PKS 控制器 API 的可用性。操作和开发将 API 请求直接指向 GSLB 虚拟服务器 URL 以创建和管理 K8s 集群以及部署应用程序。手动部署的应用程序（例如通过 kubectl）不会在环境之间自动复制，并在站点 B 的故障转移后需要重新部署。

您可以配置一个 CI/CD 自动化服务器，以执行针对每个环境中的 K8s URL 的构建管道，或者针对 GSLB 虚拟服务器 URL 的单个构建。基于 Harbor 策略的复制，这是一个内置功能，负责将镜像克隆到备用位置。您可以在环境之间复制数据存储以支持 PV。在站点 A 失败后，Pods 将在站点 B 重新部署，挂载原始持久卷的 VMDK 文件。

摘要

在这个数字化趋势的背后，有一个名为云原生的新 IT 方法，它是商业数字化的推动力之一。云原生方法允许企业大幅提高开发者的生产力，使他们能够比以前更快地将新应用和服务推向市场；因此，他们可以改善客户体验和满意度。如果成功采用，云原生方法还可以帮助降低运营和基础设施成本，以及增强应用安全性。

在下一章，第十四章，《机器学*的高性能计算》，你将了解可以增强高性能计算（HPC）环境生产力的虚拟化具体方面。我们将探讨 VMware vSphere 提供的功能，以满足研究计算、学术、科学和工程高性能计算工作负载的需求。

第十四章：高性能计算

在本章中，我们将了解可以增强高性能计算（HPC）环境生产力的虚拟化特定方面。我们将关注 VMware vSphere 提供的能力，以及虚拟化如何提高科学生产力。

我们将探讨 vSphere 功能，例如单根 I/O 虚拟化（SR-IOV）、远程直接内存访问（RDMA）和 vGPU，以构建和满足研究、计算、学术、科学和工程工作负载的需求。

本章涵盖了以下主题：

• 虚拟化 HPC 应用

• 保证资源的多租户

技术要求

您可以从my.vmware.com/en/web/vmware/info/slug/datacenter_cloud_infrastructure/vmware_vsphere/6_7下载 vSphere Scale-Out。

虚拟化 HPC 应用

本章描述了 VMware 在支持 HPC 应用方面的工作。第一部分详细描述了客户在使用 HPC 环境中的虚拟化所识别出的许多价值。第二部分展示了在 HPC 环境中部署虚拟化的几个示例，第三部分讨论了性能的各个方面，从检查性能的一些核心方面开始，然后转向吞吐量应用和并行分布式消息传递接口（MPI）应用的性能。还包括指向一些技术出版物，这些出版物将对考虑虚拟化其 HPC 工作负载的人感兴趣。

大多数 HPC 系统都是集群，它们是通过某些互连（如以太网或InfiniBand（IB））连接的计算节点集合。集群的大小可以从几个节点到数万个节点不等。HPC 集群的存在是为了运行 HPC 作业，而这些作业在集群中的放置由分布式资源管理器（DRM）处理。DRM 是中间件，它为 HPC 用户提供了一种在负载均衡的方式下将他们的 HPC 作业启动到 HPC 集群上的能力。

用户通常使用命令行界面来指定他们想要运行的工作或作业的特征，然后 DRM 将这些请求排队并调度作业在集群中负载最低、配置适当的节点上运行。有许多 DRM 可供选择，包括开源和商业的。例如包括 Grid Engine（Univa）、LSF（IBM）、Torque、可移植批处理系统（PBS）和 Slurm。DRM 也被称为批处理调度器。IB 是一种高带宽、低延迟的互连，常用于 HPC 环境中以提升代码/应用程序/作业的性能以及提高文件系统性能。IB 不是以太网，它不使用 TCP 或任何标准网络堆栈，并且目前只能通过 VM 直接路径 I/O（透传模式）在虚拟环境中使用。

本章的目的是不解释虚拟化是如何工作的。x86 虚拟化从 20 世纪 90 年代末在斯坦福大学发明时使用纯软件方法发展到目前的情况，即英特尔和 AMD 都相继增加了对虚拟化的更多硬件支持，如 CPU、内存和 I/O。这些硬件增强功能以及日益复杂的虚拟化软件，大大提高了对不断增长的工作负载的性能。这是一个重要观点，因为 HPC 人员经常听说，当 HPC 应用程序虚拟化时，其性能非常差，有些情况下甚至运行得非常好，甚至在大多数情况下非常接*原生性能。大规模整合不适合 HPC 环境，因此虚拟化对 HPC 的价值可以在其他地方得到利用。

现在我们将学*客户和我们自己研究确定的 HPC 虚拟化用例。由于 HPC 包括如此广泛的工作负载和环境，其中一些可能比其他一些更符合特定客户的需求。HPC 集群在所有主机上托管单个、标准的操作系统和应用程序堆栈，因为一致性使我们能够通过限制这些环境中的不同用例选项来轻松调度作业，例如需要从单个共享资源中服务的多个用户组。由于这些传统集群无法满足多个组的需求，它们鼓励在组织内创建分散的专用计算岛，这既低效又昂贵。

带有保证资源的多租户

客户希望利用现有的硬件和软件投资，例如在虚拟机管理程序或物理硬件上，以及直接部署到公共云的可行性。我们可以通过一个能够跨多个平台和多个云管理的服务自动化解决方案来解决这个问题以及相关的服务。该解决方案可以通过其自动化工具抽象核心任务来自动化所有手动过程的服务配置，然后管理这些自动化的访问和控制。自动化只有在将其与策略链接时才非常有用。基于策略的控制和治理为我们提供了控制驱动云解决方案的自动化应用的能力。云服务门户和目录为最终用户提供自助、按需访问授权服务。

所有现代 x86 系统都是非一致性内存访问（NUMA）系统，这意味着内存直接连接到系统中的单个 CPU 插槽。这意味着从本地插槽访问内存可以非常快，但访问连接到另一个插槽的内存将会较慢，因为请求和数据必须通过插槽之间的通信路径进行传输。这就是为什么它被称为非一致性内存访问。有时，工作负载在虚拟环境中比在裸机环境中运行得更快。这尤其适用于吞吐量工作负载，通常是由于 NUMA 效应。重点不在于虚拟化可以比裸机运行得更快，而在于虚拟化的性能对于某些高性能计算（HPC）工作负载来说可以接*裸机性能。实时迁移可以用来提高 HPC 环境的效率和灵活性。它还可以用来提高弹性。在传统的裸机 HPC 环境中，作业是静态放置的。考虑以下场景：应用程序 C 必须被调度，但目前没有足够的资源节点可供其运行。

在裸机环境中有两个选择：

• 应用程序 C 可以在队列中等待，直到应用程序 A 或 B 完成

• 可以终止应用程序 A 或 B 来为应用程序 C 腾出空间

这两种选项都会降低集群的工作吞吐量。在终止作业的情况下，如果运行的应用程序是昂贵的独立软件供应商的应用程序，那么工作量的损失可能会非常昂贵。在虚拟环境中，解决方案是使用实时迁移来移动工作负载，为应用程序 C 腾出空间。这种方法主要适用于这些作业相对长时间运行的环境。

让我们看看实时迁移的另一种用途：提高集群的整体吞吐量。考虑裸机环境中运行的两个作业。当第三个作业启动时，它可能比用户预期的消耗更多内存。这将导致系统上的其他作业绑定到交换空间，从而以负面方式影响这些作业的整体性能。动态资源调度器（DRS）可以在虚拟环境中解决这类情况：当第三个作业开始消耗所有可用内存时，DRS 可以将过载的虚拟机转移到负载较少的其他机器上，并帮助作业以期望的性能继续运行。

这种对特定组或部门资源使用保证的缺乏是裸机环境集中化的另一个障碍。例如，一个大型计算岛的所有者通常不愿意将他们的硬件资源捐赠给共享池，如果他们不能保证在需要时至少可以访问那些资源。DRS 提供了满足这一需求的能力。快照可以用来保存正在运行的虚拟机的状态，以防止硬件故障；当机器失败时，虚拟机被恢复，应用程序从快照被捕获的点继续执行。

在概念上，这与 HPC 中使用的检查点机制相似，但不同的是，我们不是从正在运行的操作系统提取进程的状态，这通常受到各种限制，而是利用虚拟机和底层虚拟平台之间存在的干净抽象。更高级的弹性方案（主动高可用策略）将使用底层系统的遥测数据来预测即将发生的硬件故障，然后主动将工作负载从可疑的主机迁移到其他主机，以避免应用程序中断。例如，一个运行重要作业的系统上的风扇故障或检测到的软内存错误率的增加，这可能会表明即将发生的硬内存错误概率增加。

尽管这种方法可能不会消除检查点的需要，但它可能会减少这种需要。更频繁的检查点操作和从检查点更频繁的恢复可以增加集群上的整体作业吞吐量。

关键用例 - 统一

一些管理人员的愿望是将他们的 HPC 工作视为仅仅是另一种工作负载，并从部分虚拟和部分物理基础设施转向全部虚拟基础设施，以获得更大的灵活性和可管理性。这是一个我们金融服务客户所做的部署的简单例子。在这种情况下，中央 IT 部门创建了一个共享的计算资源，可以向组织内的不同业务线出租虚拟集群。需要一段时间访问集群的组将收到一组虚拟机，而不是用于指定时间段的物理机器。

组织从中获得的益处如下：

• 业务线（LOBs）在需要时获得所需的资源

• 集群和集群节点可以根据 LOB 的应用需求进行规模调整（例如，大多数进程运行仅消耗每个作业的单个 CPU；它们是串行（不是并行）作业）

• 中央 IT 团队能够从可用的硬件中提取最大价值

• 硬件足够灵活，可以在各种作业之间共享，同时用户/工作负载之间保持安全合规

• 可以通过策略强制执行 LOB 之间的相对优先级，以确保（例如）具有硬截止日期的组获得底层硬件资源的更高公平份额：

为了在 vSphere 上为 HPC 应用程序实现最佳性能，配置平台级（有时是客户机级）调整以获得某些好处。由于 HPC 应用程序（与大多数企业应用程序不同）对延迟敏感，因此需要进行调整。这种敏感性可能存在于存储、网络或通信互连中。

虽然 VMware 的目标是为任何应用程序提供出色的即插即用性能，但 HPC 工作负载对我们来说相对较新，因此需要进行一些调整。我们已经开始通过配置 vCenter 高级虚拟机参数来自动设置一些可调整参数，我们打算在这些参数中运行对延迟敏感的工作负载。随着时间的推移，这种自动调整将变得更加全面。

客户最初的网络文件系统存储（NFS）基准测试体验直接指向了一些存储延迟问题。通过调整任何 NFS 数据传输背后的网络堆栈，我们能够直接提升应用性能，正如在裸机环境中所见。默认情况下，网络通过在企业环境中高效地通过大量数据来优化吞吐量。这意味着，当数据包到达时，它们可能不会立即被处理。

通常，在系统醒来并处理整个批次之前，允许少量消息积累。这减少了 CPU 的负载，但会减慢消息传递。在数据到达是性能瓶颈的情况下，更合理的是花费更多的 CPU 周期来及时处理每个到达的数据包。这在 HPC 工作负载中通常是这种情况。虚拟和物理网络设备都应该关闭合并，以实现这一变化。

在传输控制协议（TCP）堆栈的更高级别存在另一个合并级别（在客户机内禁用大接收卸载（LRO））——它应该被关闭。我们评估了一些实验的结果，以查看虚拟化引入的额外内存抽象级别是否对 HPC 应用程序性能有任何影响。

特殊情况是那些几乎没有空间数据局部性的应用程序。这包括那些无法有效使用其缓存的应用程序，因为它们不以常规方式访问内存，例如随机访问基准测试。除非在特殊情况下，通过在客户操作系统中使用大页面可以大大减少开销，否则它不会受到影响。关闭 EPT（AMD 上的 RVI）并恢复基于软件的页表方法也可以在这种特殊情况下有所帮助。由国家安全局（NSA）创建，它甚至更新随机内存位置时也没有局部性。

这些工作负载会引发大量的翻译查找缓冲区（TLB）缺失。由于页表缓存中的缺失频繁发生，如果该操作缓慢，应用程序可能会变慢。实际上，英特尔和 VMware 创建的 EPT 和 RVI 技术，尽管在硬件中实现，但在处理 TLB 缺失方面比 VMware 开发的较老影子页表方法要慢。通过使用更大的页面可以减少 TLB 缺失，因此在这些情况下关闭 EPT 或 RVI 可能会有所帮助。

事实是，EPT 和 RVI 在绝大多数情况下表现良好，但保持这个问题在心中是有益的。高性能 LINPACK（HPL）像其他高性能计算（HPC）应用程序一样很好地使用缓存，并获得了更好的性能。我们可以看到，对于这种应用程序类型，性能是一致的优秀。

这是针对运行需要大量线程的应用程序且虚拟机将跨越主机内多个 CPU 插槽的高性能计算（HPC）客户的虚拟化平台的一个重要方面。

ESXi 已经对NUMA（非一致性内存访问）有感知，这意味着当它运行虚拟机时，它会小心地将执行线程放置在托管虚拟机内存的相同插槽上，以便所有内存访问都是本地的。当一个虚拟机跨越两个插槽时，我们将类似的线程分布在两个插槽上，然后在本地插槽上分配内存以提供最佳性能。因此，即使虚拟机足够大，可以跨越多个插槽，它也不会看到底层硬件的 NUMA 特性。我们引入了 vNUMA，使 NUMA 拓扑对客户操作系统可见，然后可以根据这些信息进行自己的优化。这在性能方面可能非常重要。

高性能计算集群性能

标准性能评估公司 OpenMP（SPECOMP）是针对在多个节点上运行的多线程应用程序的知名高性能计算（HPC）基准测试套件。每个基准测试（例如，Swim）都列在 x 轴上。

对于每个基准测试，有三个比较对：一个用于 16 个 vCPU 虚拟机，一个用于 32 个 vCPU 虚拟机，一个用于 64 路虚拟机。默认-16 表示没有 vNUMA 支持的 16 路虚拟机的性能，而 vNUMA-16 表示相同的 16 路虚拟机，但启用了 vNUMA。

与原生相比的比率，越低越好：

图表显示了运行时间，所以越低越好。我们可以看到，在从默认值切换到 vNUMA 时，几乎所有情况下都会出现显著的运行时间下降。这对于需要广泛虚拟机的 HPC 用户来说是一个非常重要的功能。这些图表显示了在 ESXi 上运行的多种生命科学工作负载的已发布性能结果。

他们表明，这些以吞吐量为导向的应用程序在虚拟化时通常低于 5%的惩罚。来自客户的最新报告表明，这一类应用程序（吞吐量），不仅包括生命科学，还包括金融服务、电子设计自动化（EDA）芯片设计者和数字内容创作（电影渲染等），其性能下降都远远低于 5%。要实现这些结果，需要平台调整而不是应用程序调整。

我们有来自 EDA（芯片设计）客户的结果报告，他们在裸金属 Linux 节点上首先运行了他们 EDA 作业的一个实例。然后，他们在 ESXi 上运行了相同的 Linux 和相同的作业，并比较了结果。他们看到了 6%的性能下降。我们相信，通过额外的平台调整，这个数字会更低。

然后，他们进行了第二次测试，将四个应用程序实例在一个 Linux 实例中运行与四个运行相同作业的虚拟机进行了比较。因此，在这两种情况下，我们都有相同的工作负载。在这个配置中，他们发现虚拟作业比裸金属作业提前 2%完成。

HPCC 性能比率（越低越好）：

这种加速通常源于 NUMA 效应和操作系统调度效应。Linux 实例必须在四个作业实例之间进行资源平衡，并且还必须处理与这是一个多插槽系统相关的 NUMA 问题。

虚拟化将帮助我们获得以下优势：

• 每个 Linux 实例只需处理一个作业

• 由于 ESXi 调度器的 NUMA 意识，每个虚拟机将被调度到插槽上，这样 Linux 实例就不需要承受处理 NUMA 问题的潜在低效。

我们不必担心多个 Linux 实例和虚拟机消耗更多内存：透明页面共享（TPS）可以缓解这一点，因为虚拟机管理程序将在虚拟机之间找到公共页面并在可能的情况下共享它们。

标准的 Hadoop 架构

让我们了解一个标准的 Hadoop 架构：

• Hadoop 文件系统（HDFS）：一个分布式文件系统，在 Hadoop 集群中连接到计算节点的本地磁盘上实例化

• 地图：将应用于从 HDFS（并行）读取的每一块数据的令人尴尬的并行计算

• 减少：将映射结果组合起来执行最终计算的阶段

最终结果通常存储回 HDFS。Serengeti（开源项目）的好处提供了部署便利性、多租户和可扩展性，可以向上或向外扩展。BDE 允许从 vRealize 蓝图触发 Serengeti，使得自提供指定大小的 Hadoop 集群变得容易：

前面的图显示了虚拟化的 Hadoop 环境。本地磁盘作为 VMDK 提供给虚拟机、Map 和 Reduce 任务，这些任务在每个 Hadoop 集群节点上运行。

我们方法的新一代是其中有两种类型的 VM：计算节点和数据节点。数据节点负责管理连接到主机的物理磁盘和 HDFS。计算节点运行 Map 和 Reduce 任务。计算节点和数据节点之间的通信通过快速的 VM-VM 通信进行。

标准测试

这些测试是在一个 32 节点（主机）集群上运行的，该集群具有本地磁盘和 10 Gbps 以太网互连。最重要的点是运行了四种配置，每种配置都解决了相同的问题：

• 配置 1：一个 32 个主机的物理集群

• 配置 2：一个 32 个 VM 的虚拟集群

• 配置 3：一个 64 个 VM 的虚拟集群（每个主机有两个 VM，每个 VM 使用一半的硬件）

• 配置 4：一个 128 个 VM 的虚拟集群（每个主机有四个 VM，每个插槽上有两个，每个 VM 拥有四分之一的硬件资源）

我们使用常见的基准测试来评估 Hadoop 性能的各个方面。以下是虚拟运行时间与本地/物理/裸机运行时间的比率：

• TeraGen：6%，4%，3%

• TeraSort：13%，1%，-1%

• TeraValidate：5%，5%，7%

通常，将问题分解成更小的部分并运行更多的 VM 可以使性能更接*本地。

在 MPI 应用程序中发现了广泛的延迟敏感性。粒子网格 Ewald 分子动力学（PMEMD）的应用程序是一个分子动力学代码，其中超过 40% 的 MPI 数据传输涉及单字节长度的消息。与此相比，格子玻尔兹曼磁流体动力学（LBMHD）代码的所有消息大小都大于 1 MB。第一个应用程序对互连延迟非常敏感，而第二个则不敏感，而是带宽限制。

每个应用程序都有其自己的与其他应用程序的进程流程的通信模式。进程/处理器编号显示在 x 和 y 轴上。在 (x, y) 处的数据点越暗，x 和 y 进程之间的数据传输就越多。PMEMD 模式显示每个进程与可用进程范围内的所有进程进行通信，但与附*/相邻进程的通信更多。有些算法中，显示的模式将是整个模式上的深色区域，表示所有进程之间有强烈的通信。

在 HPC 裸机环境中，绕过内核以获得最低延迟下的最佳带宽是很常见的，这对于许多 MPI 应用程序来说很重要。而不是使用标准的 TCP 网络堆栈（这会增加开销），远程直接内存访问（RDMA）设备，例如 IB，允许直接从应用程序启动和终止传输，而不使用主机 CPU 来传输数据：

我们可以为我们的虚拟环境选择模拟方式。我们可以通过 VM 直接路径 I/O 使硬件设备，如 IB，直接对虚拟机可见（前图中最右侧的rdma框），这将允许应用程序通过使用 ESXi 直接访问硬件，就像裸机案例一样。VM 直接路径 I/O 左侧的rdma框代表了 VMware 内部开发 vRDMA 设备的工作，这是一个虚拟化 RDMA 设备。

此设备将继续允许直接应用硬件访问进行数据传输，同时继续支持执行快照和使用 vMotion 的能力。这代表了一项持续的工作，将使 RDMA 方法可用于 ESXi 本身以及 ESXi 服务，如 vMotion、vSAN 和 FT。我们已经展示了使用 RDMA 传输的 vMotion 在性能上的显著提升。

英特尔测试了各种 HPC 基准测试

高性能计算集群（HPCC）：

HPC 挑战基准测试是多个基准测试的组合，用于测试各种属性以及 HPC 系统的性能。STAR-CD 是一种用于缸内分析的计算流体动力学（CFD）代码。这些是负责在多个节点上多进程运行的消息传递接口（MPI）代码。结果是在几个配置的小集群中：2 节点，16 个进程；4 节点，32 个进程；8 节点，64 个进程（在 HPC 领域，“节点”意味着“主机”）。即使对于这个旧配置，我们也展示了与原生环境的优秀一致性。英特尔应该关闭 EPT 或使用大页面大小以获得更好的 MPIRandomAccess。我们尚未探索自然排序的环形带宽以了解那里的问题。

HPCC 代表一套应用，例如覆盖 HPC 需求范围的基准测试。我们做得如此之好是非常积极的，即使这确实是在非常低的规模上。在我们查看 STAR-CD 的结果之前，查看应用程序的消息特性是有用的。

MPI 应用程序在进程之间执行两种类型的通信：

• P2P：单个进程从另一个进程发送或接收数据

• 集体操作：许多进程共同参与，以某种模式之一传输数据

STAR-CD 交换的大多数 P2P 消息在 1 KB - 8 KB 范围内。我们将这些定义为中等大小的消息。随着节点数量的增加，更多的这些消息移动到 128 B-1 KB 范围内。这意味着随着节点数量的增加，互连延迟成为一个更重要的因素。对于集体操作，Star-CD 有一个非常明显的延迟敏感性，因为几乎所有消息都落在 0 - 128 B 范围内。

这两个图表的 y 轴是不同的。Star-CD 比集体操作更频繁地使用 P2P 消息。因此，尽管集体操作非常延迟敏感，但由于集体操作并不代表 STAR-CD 传输消息的大多数，延迟开销的整体影响可能有所减少。结果显示，使用 STAR-CD 运行 A 类模型（梅赛德斯汽车车身）时，速度慢了 15%，使用了 8 个节点和 32 个进程在双插槽节点上。

这对许多 HPC 用户来说是一个显著的减速，这就是我们继续在平台上表征和减少延迟开销的原因。我们下一组的结果是使用 VM 直接路径 I/O 与 QDR（每秒 40 吉比特）IB 和 ESXi。

在广泛的报文大小范围内，裸金属和虚拟化使用两种不同的传输机制：发送和 RDMA 读取。我们在虚拟情况下提供等效的带宽。

裸金属和虚拟环境在广泛的报文大小范围内混合运行时间（HRT，作为内核运行的运行时间）的延迟不同，并取决于许多因素。这些结果是通过 RDMA 读取操作生成的。使用四倍数据速率（QDR）（每秒 40 吉比特）IB 和 ESXi，虚拟化引入了大约 0.7 微秒的额外延迟，在最小报文大小上这是显著的，而对于较大的报文则不那么显著。

当在相同硬件上使用发送/接收操作时，ESXi 的延迟开销降至大约 0.4 微秒，并且对于大于 256 字节的报文大小，这种差异消失了。再次强调，这些开销对性能的影响将完全取决于感兴趣的具体应用的消息特性。用于计算的 GPU，称为通用 GPU（GPGPU），有令人鼓舞的结果。客户可能对英特尔在这一领域的加速产品，英特尔至强 Phi 感兴趣。

平台必须适当调整以支持这些应用所需的延迟，这是至关重要的。我们在平台上什么工作得好，什么工作得不好方面非常透明，以便客户能够准确了解虚拟化 HPC 工作负载和环境的值和挑战。

摘要

在本章中，我们讨论了虚拟化的特定功能，这些功能增强了 HPC 环境的成果。我们关注了超越通用虚拟化平台独特功能的特点，并探讨了虚拟化如何提高科学生产力。虚拟化对特定模拟或计算运行时间的影响可能不同，但计算部署的整体性能具有最佳吞吐量。

本书将帮助您将客户的运营目标与他们的商业目标对齐。读者将学*到 IT 组织如何通过解决关键商业问题，为他们的企业提供安全且灵活的数字基础，从而实现运营和商业目标。他们还将学*到 VMware 产品如何帮助客户向企业提供一致且稳定的 IT 性能。VMware 建议利用即插即用的超融合、虚拟化资源，以加速完全虚拟化基础设施的部署。

读者现在应该了解一个完全虚拟化的基础设施如何帮助他们加速部署，统一和简化操作、监控和 IT 管理，同时提高扩展能力。软件定义的基础设施使我们能够统一并简化操作、监控和 IT 管理，同时提高可扩展性。本书中提到的所有解决方案都采用了软件定义的方法来构建私有云，这种方法通过通用硬件将虚拟化扩展到整个数字基础设施（计算、存储和网络），这些硬件可以通过通用的现有工具和技能集进行管理。