在 Google 云计算引擎上调整 VDA 实例的大小

简介

本文档为在 Google 云计算引擎上部署 Citrix 工作负载 (VDA) 的企业提供了单实例可扩展性和经济性指导。重点是在谷歌计算引擎虚拟机实例上运行的托管共享工作负载(安装了 RDSH 角色的 Windows Server VDA)。秤测试是使用繁重、可重复的合成工作负载进行的,目的是提供保守但可行的指导。最后,我们将提供一些谷歌云 VMware 引擎的规模调整指南。

执行摘要

这项研究的结果表明了以下几点:

  • 对于很大比例的用例(工作负载),Citrix VDA 的性能往往受到 CPU 与磁盘或网络的限制。
  • 在发布之时,Google Cloud上提供的最新处理器提供了最佳的最终用户体验(根据我们繁重的参考工作量进行衡量)。它们在 N2、N2D 和 C2 实例系列中可用,并利用英特尔的 Cascade Lake 和 AMD 的 Milan 处理器。
  • 谷歌的 Tau 系列虚拟机无法用于此次测试,但可能值得考虑用于 Citrix VDA 工作负载。
  • 4 个 vCPU 和 8 个 vCPU 的实例大小往往提供最高的密度和最低的每位用户成本。
  • 对于我们繁重的测试工作负载,N2D-Standard-8 实例类型(采用 AMD Milan 处理器)最具成本效益,按公布的定价计算,每用户小时的成本低至 0.028 美元。
  • 使用最新的处理器,用于永久性磁盘的存储类型不会对实例的可扩展性产生实质性影响。
  • 虽然本研究没有进行明确测试,但需要 GPU 的工作负载必须在 N1 实例类型上运行。在需要GPU加速的情况下,利用Skylake处理器和高级SSD永久性磁盘存储可能会产生最佳性能和最高的可扩展性。

可伸缩性注意事项

在本节中,我们将讨论影响单服务器可扩展性的一些关键因素,例如工作负载、CPU 过载、处理器体系结构和存储选择。

用于测试的工作负载选择应接近环境中的用户。例如,如果 50% 的用户产生了较轻的用户负载,30% 的用户产生了中等负载,而其余 20% 的用户产生了繁重的工作负载,那么使用中等工作负载将使您大致了解预期的结果。 但是,如果您的环境中有 20% 的用户产生较轻的用户负载,而 80% 的用户产生了繁重的工作负载,那么使用繁重的工作负载将为您提供最佳的近似值。

理想的情况是使用自己的工作负载执行可扩展性测试,而不是依赖从我们的测试中得出的可扩展性数字。Login Enterprise 的一个有用功能是,您可以轻松创建自己的自定义工作负载,或者从提供的开箱即用的应用程序工作流中构建工作负载。在本次测试中,我们希望选择一种能够代表大多数用户的工作负载,并提供相关数据以供比较,同时为那些未对自己的工作负载执行可扩展性测试的企业提供保守的估计。

另一个考虑因素是实例上的用户与 vCPU 的比率。 该比率是根据虚拟机上预期的用户数与存在的 vCPU 数量来表示的。例如,如果我们预计每个 vCPU 有 2 个用户,则该比率将表示为 2:1。 由于 CVAD 工作负载是 CPU 密集型的,因此过量使用率通常用于估算,我们为推荐的实例类型提供该比率。每个 vCPU 的用户数量可能因工作负载、CPU 处理器架构甚至主机中的可用内存量而异。

处理器架构也会对可扩展性结果产生影响,正如人们对CPU密集型工作负载所预料的那样。本研究的目标之一是确定哪些计算实例系列和形状在 Google Cloud 上最具成本效益。在所有条件相同的情况下,速度更快的处理器通常比速度较慢的处理器为每个实例提供更多的用户,但通常需要额外付费。

虚拟机上用于永久性磁盘的存储类型和大小可能会影响单服务器的可扩展性,因为本地磁盘用于交换内存和存储用户配置文件。更快的磁盘可以减少磁盘延迟,从而加快读/写操作。如果磁盘存储用户配置文件的空间不足,或者内存交换检索时间延迟较长,则主机的整体性能将降低。 在 Google Cloud 上为永久性磁盘使用高级 SSD 存储可以最大限度地减少存储瓶颈,并确保我们测试的是实例类型而不是存储的计算。为了评估存储,我们将实例类型保持静态并改变磁盘类型。

另一个因素是会话的启动率。如果会话启动得很快(比如每 10 秒 1 个会话)与中等(每分钟 1 个会话)启动会话,则会发现不同的结果。登录风暴会给环境带来压力,您应始终计划有足够的容量来支持高峰登录期。但是,可扩展性测试通常以中等的登录速率完成,即每 30 秒或 60 秒一个会话,具体取决于工作负载强度。较长的间隔可以更准确地查看稳定状态下可以支持的活动会话的数量。

测试环境

对于可扩展性测试,基础架构虚拟机配置如下:

  • 运行版本 4.5.11 的 One Login Enterprise 虚拟设备
  • 四个在 e2-standard-2 实例上运行的 Login Enterprise 启动器,会话启动间隔为 1 分钟
  • 一个 Citrix Cloud Connector
  • 一个 Active Directory 域控制器同时充当配置文件服务器和 DNS 服务器

Citrix 工作负载在具有以下已配置软件的单个 Windows Server 2019 数据中心实例上运行:

  • 已安装Microsoft RDSH 角色,包括桌面体验
  • Citrix 服务器多会话操作系统 VDA 2103.0.0.29045
  • Microsoft Office 2019
  • Microsoft Defender 使用默认设置
  • 测试时提供最新的 Windows 更新(2021 年 9 月)
  • 除非另有说明,否则使用了开箱即用的设置

实例类型

在这项研究中,我们首先选择了我们期望最有效地利用资源的机器系列,包括以下几种:

  • N1(支持 GPU 的通用英特尔 Skylake)
  • N2(通用英特尔喀斯喀特湖)
  • N2D(通用型 AMD)
  • C2(计算优化工作负载英特尔 Cascade Lake)
  • E2(成本优化的英特尔 Skylake)

注意:

Google 的 Tau 系列 T2D 实例在测试时不可用,但根据此处详述的结果,我们对它们抱有很高的期望。

我们首先评估所选计算机系列的 8-vCPU 版本,然后评估结果以确定性能最佳的机器。然后,我们更进一步,评估了这些机器系列中的 4-vCPU 和 16-vCPU 版本。已在以下虚拟机实例类型上完成测试运行:

  • n1-standard-8 (Skylake)
  • n1-highcpu-8 (Skylake)
  • n1-highmem-8 (Skylake)
  • n2-standard-8 (Cascade Lake)
  • c2-standard-4 (Cascade Lake)
  • c2-standard-8 (Cascade Lake)
  • c2-standard-16 (Cascade Lake)
  • e2-standard-8 (Skylake)
  • n2d-standard-4 (Rome)
  • n2d-standard-8 (Rome)
  • n2d-standard-16 (Rome)
  • n2d-standard-4 (Milan)
  • n2d-standard-8 (Milan)
  • n2d-standard-16 (Milan)

我们很早就了解到,机器系列的 2-vCPU 版本不太适合我们繁重的参考工作负载。出于这个原因,我们的测试重点是 4-vCPU、8-vCPU 和 16-vCPU 实例形状。

在不同的测试运行中,使用 Login Enterprise 在每个实例类型上模拟用户会话,以分析不同虚拟机实例类型和形状的可扩展性。

实验室架构

用于会话代理和管理的所有基础架构均由 Citrix Cloud Virtual Apps and Desktops 服务提供。在 VPC 中安装了 Active Directory 域控制器和Cloud Connector,从而在谷歌云上创建了一个资源位置。下图描述了测试架构。

实验室架构

注意:

N2 和 N2D 实例在 US-West2 区域不可用,因此它们是在美国西部 1 区域创建的。

使用最终用户体验 (EUX) 分数登录企业知识工作负载

此版本的 Login Enterprise 提供了一种将虚拟用户的工作流构建为常用 Office 365 知识工作负载的方法。该测试与 Login VSI 密切合作,还使用了名为 EUX 分数的实验性评分系统。EUX 分数是一种量化用户在桌面或应用程序会话中的体验或感觉的响应能力的方法。该用户的工作流程包括以下应用程序:

  • 登录 VSI EUX 分数申请
  • Microsoft Outlook
  • Microsoft Word
  • Microsoft
  • Microsoft PowerPoint
  • Microsoft Edge
  • YouTube

在 100% 并发使用时,登录企业知识工作器是一项繁重的 CPU 密集型工作负载,在测试的云实例上,每个 vCPU 平均允许 2 个用户使用。

在会话期间,EUX 评分应用程序多次执行一组指令并记录执行每个步骤所需的时间。然后,这些 结果可用于生成会话的 EUX 分数。熟悉旧版 Login VSI 应用程序的人会发现这些操作很熟悉。

理论上最高 EUX 分数为 10,但是,在不同工作负载下,与其自身相比,该分数更有用。例如,如果我们在 EUX 平均得分为 7.59 的 c2-standard-8 上查看相同的用户负载, 我们会看到此图,其中实线表示 n2d-standard-8 实例,虚线表示 c2-standard-8 实例。该图清楚地显示了n2d-standard-8实例,其平均EUX分数为8.07,在整个测试过程中表现优于c2-standard-8实例。您还可以看到系统忙碌时分数如何略有下降。

EUX 分数趋势线

平均 EUX 分数虽然不能完美地反映整个测试运行,但确实提供了特定配置在工作负载条件下可能表现的指标。 下表显示了运行 EUX Workload 的单个用户在不同机器类型配置下的 EUX 分数。

  vCPU 内存 (GiB) EUX 分数(单用户)
N2D-Standard-4-Milan AMD 4 16 8.61
N2D-Standard-8-Milan AMD 8 32 8.54
c2-Standard-8 喀斯喀特湖 8 32 8.5
c2-Standard-16-喀斯喀特湖 16 64 8.4
n2D-Standard-16-Milan AMD 16 64 8.35
c2-Standard-4-喀斯喀特湖 4 16 8.13
n1-highmem-8-Skylake 8 42 7.75
n1-standard-8-Skylake 8 30 7.7
N2D-Standard-8-Rome AMD 8 32 7.7
n2d-Standard-16-Rome AM 16 64 7.7
n1-highcpu-8-Skylake 8 7.2 7.56
N2-Standard-8 喀斯喀特湖 8 32 7.56
e2-standard-8-Broadwell 8 32 7.45
N2D-Standard-4-Rome AMD 4 16 7.29

当单独用于单个用户时,EUX 分数确实提供了一个相对较好的指标,表明虚拟机在测试工作负载中的最大性能潜力。遗憾的是,EUX 分数无法提供足够的数据来确定特定实例类型可以支持的用户数量。为此,我们需要测量和评估其他标准,例如CPU利用率和新的Windows用户输入延迟性能计数器。

计分方法

分析任何系统上的测试结果始终是一项挑战,需要对系统中的多个组件进行分析。由于我们在每台主机上使用相同的测试,因此测试结果足够一致,可以比较实例配置。为了得出特定实例类型支持的估计用户数,我们还测量了两个关键性能计数器:CPU 使用率和用户输入延迟。

CPU 使用率: 此计数器(处理器 (_Total)% 处理器时间)度量处理器的所有 vCPU 忙于执行非空闲线程任务所用时间的百分比。CPU 使用率历来是衡量用户体验的最佳指标之一,因为随着 CPU 利用率接近满负荷,用户体验会迅速下降。

在此分析中,根据处理器总时间计算出一分钟的移动平均值。当移动平均线达到85%时,我们查看了系统上的用户数量,再次达到90%。

用户输入延迟: 此计数器(每个会话的用户输入延迟(最大值)\ 最大输入延迟)测量从队列中取出并处理用户输入(如鼠标或键盘)所花费的时间。此计数器很好地表明了用户体验,因为延迟超过一秒钟时用户会注意到延迟。

在此分析中,根据会话主机上任何用户经历的最大用户延迟计算出一分钟的移动平均值。例如,如果系统上有 3 个用户,并且所有三个用户都经历了用户延迟,则输入延迟时间最高的用户将是为移动平均选择的用户。我们查看了最差体验的移动平均线达到 1 秒(1000 毫秒)延迟时以及延迟达到 2 秒(2000 毫秒)时系统中的用户数量。请记住,并非所有用户都会遇到这种类型的延迟,但是当所有鼠标和键盘移动都有 2 秒延迟时,任何一个用户都足以保证呼叫帮助台。

这两个范围为我们提供了实例类型可以支持的用户数量的数据点。

最小用户数: 通过比较CPU利用率为85%的用户数量和用户输入延迟为1秒的用户数量并选择最低数字来计算。 最大用户数: 通过比较CPU利用率为90%的用户数和用户输入延迟为2秒的用户数量并选择最低数字来计算。

预期用户

在确定预期成本之前,我们需要先确定在某个实例类型上成功运行了多少用户。事实证明,这比最初的预期更具挑战性,因为EUX Scording系统没有告诉我们在性能下降到不可接受的水平之前可以容纳该系统的用户总数,而是系统上所有用户的总体体验。

如上所述,使用 CPU 使用率和用户输入延迟计数器的组合,我们能够确定特定实例类型的预期用户范围。诚然,度量边界(85-90% CPU和1-2秒输入延迟)的选择似乎有点武断,但就我们的目的而言,它提供了一个与EUX分数结合使用的参考点。最后,我们决定使用以下计算方法为预期用户选择最保守的数字:

预期用户:对于通过 99% 或更高的测试运行,计算出以下各项的最小值:

  1. 用户在测试运行期间登录
  2. 用户在最大 UID 1 分钟移动平均线高于 1 秒时登录
  3. 用户在最大 UID 1 分钟移动平均线高于 2 秒时登录
  4. 用户在 CPU 1 分钟移动平均线高于 85% 时登录
  5. 用户在 CPU 1 分钟移动平均值超过 90% 时登录

预期成本

下图显示了本研究测试的 8 个 vCPU 实例中每个 vCPU 实例的每位用户每小时成本。所有主机的定价均为 100 GB 高性能磁盘,适用的 Windows 许可费用已包含在总额中。

8 vCPU 系列比较

从数据中可以看出,用于此工作负载的最具成本效益的机器系列配置是 c2 标准(Cascade Lake)、n2d 标准(罗马)和 n2d 标准(米兰)。使用截至2021年11月1日美国中部1地区的机器成本,使用n2d-standard-8(米兰)配置,我们实现了每位用户每小时0.028美元的总计算和存储成本。

计算建议

如前所述,在讨论用户与 vCPU 的比率时,以下是我们测试中排名靠前的竞争者的结果:

每个 vCPU 的预期用户数

从图表中可以看出,4-vCPU 和 8 个 vCPU 实例能够达到甚至超过每个 vCPU 2 个用户的目标,其中 n2d-standard-8 Milan 处于领先地位。 这里有一个有趣的关键要点是,16 个 vCPU 实例的每个 vCPU 用户数低于预期。这让我们感到惊讶,也让您现在感到惊讶,因为通常那些较大的实例的缩放数比这更好。但是,对于这些实例类型上的这种工作负载,我们将坚持推荐 4 个 vCPU 或 8 个 vCPU 实例,每个实例类型可获得 2 个以上的用户。

一般来说,最新一代的处理器应该能够在 CPU 密集型工作负载(例如我们在本研究中使用的知识工人)上提供最佳的可扩展性。每个vCPU拥有最高用户的类型包括两代AMD EPYC芯片(罗马和米兰),并且只有最新的英特尔(Cascade Lake)处理器,这是因为我们只选择了性能最好的三种类型。

事实证明,当实例类型提供两种处理器类型之间的选择时,我们能够在处理器代之间提供一些比较数字。不幸的是,这意味着我们无法将在 N2 或 C2 实例中运行的 Cascade Lake 处理器与在 N1 实例中运行的前几代处理器直接进行比较。但是,我们能够比较英特尔的Broadwell和Skylake处理器以及AMD的罗马和米兰EPYC处理器。下图显示了处理器对比。

处理器比较

如图所示,总体趋势是最新一代产品提供最佳性能。Google Cloud 的一个优势是,您可以为 N1 和 N2D 机器类型选择处理器一代,而且无论选择哪种处理器,成本都保持不变,因此,除非您需要或想要使用较早一代的处理器,否则请务必将 vCPU 处理器设置为最新一代。

虽然Cascade Lake处理器是英特尔的最新一代处理器,并且由于测试是CPU密集型的,因此性能可能最好,但您可能并不总是想选择最新一代的处理器。尽管此图表中没有显示,但一个奇怪的发现是,Broadwell处理器的性能偶尔会超过n1-standard-8上较新的Skylake处理器。我们认为这对于具有密集图形的应用程序是可能的,因为Broadwell处理器支持四通道内存,而Skylake处理器仅支持双通道内存。

还有一些与绩效无关的因素需要考虑。除了处理器在工作负载上的性能外,在选择机器系列和配置时还应考虑以下因素:

虚拟 GPU: 如果您的工作负载需要 GPU,那么我们测试的唯一支持 GPU 的机器系列就是 N1 系列。

可用性: 并非所有处理器世代甚至机器系列在每个地区都可用。在确定特定的虚拟机配置之前,请先查看要部署的区域并确定您有哪些计算选项。

成本: 费用因地区而异。在本文中,我们使用 US-Central1 区域来获取所有成本信息,因为该区域的成本通常最低,而且所有机器类型都可用。在某些情况下,承诺使用折扣在某些地区也可能不可用。

存储注意事项

Google Cloud 提供不同类型的块存储,用于计算实例上的永久性磁盘,每种存储都有一套针对应用程序需求的性能标准。在这项研究中,我们测试了三种最广泛使用的类型:标准、平衡和固态硬盘。

|更低的成本|<——>|更高的性能| |—|—|—| |Standard|平衡|SSD| 大计算/大数据、日志分析、冷盘|大多数企业应用程序、简单数据库、稳定状态的 LOB 应用程序、启动盘|大多数数据库, 永久缓存、横向扩展分析| |1200 IOPS、2,000 MiB/s 吞吐量 |80,000 IOPS、1200 MiB/s 吞吐量 |100,000 IOPS、1200 MiB/s 吞吐量| |每 GIB 0.04 美元|每 GIB 0.10 美元|每 GIB 0.17 美元|

我们在不同的 8-vCPU 机器系列(C2、N2D 和 N1)上进行了多次测试,在这些测试中,我们改变了磁盘类型,但计算能力保持不变。这些测试使我们能够快速比较标准、平衡和固态硬盘。结果如下表所示。

磁盘类型比较

此图表中最引人注目的一点是,vCPU 速度越快,磁盘类型对预期用户数量的影响就越小。例如,更改磁盘类型对C2和N2D机器系列的影响很小,但是N1系列在可扩展性方面存在显著差异(几乎提高了33%)。但是,请记住,标准磁盘的成本不到平衡磁盘的一半,不到固态硬盘成本的四分之一,因此,如果性能相同,从长远来看,较低的存储成本可能会有所回报。

我们的特定工作负载测试数据表明,如果在迁移到 GCP 时成本是首要考虑的问题,那么使用价格较低的磁盘不会显著影响最新一代处理器的性能。但是,使用工作负载的结果可能会有所不同,因此我们强烈建议您在提交特定架构之前测试工作负载。

使用 EUX 分数

尽管本文没有充分利用 EUX 评分算法,但我们发现它与我们分析的性能计数器有很高的相关性。最后,我们使用所有三个数据点(EUX分数、CPU利用率和用户输入延迟)来计算我们的预期用户。下图显示了系统中单个用户的 EUX 分数与预期用户负载下的 EUX 分数之间的差异。

EUX 分数对比

正如您所看到的,唯一的例外是E2-Standard-8 Broadwell,它的成绩为6.93,所有EUX分数都高于7.0。 在本次分析中,我们完成了300多次测试,在EUX分数低于7.0的所有运行中,我们都能够立即确定EUX分数较低的原因。最常见的情况是 CPU 利用率超过 90% 或最大用户输入延迟超过 2 秒。

我们更进一步地说,虽然EUX分数为7.0是绝对最低的可接受分数,但您可能会发现用户在这个水平上也不满意。从我们的测试中得出一个很好的经验法则如下:

从加载了预期用户数量的系统中获得的 EUX 分数应大于 7.0,单用户 EUX 分数应减去半分。

谷歌云 VMware 引擎的可扩展性指南

截至发布之日,Citrix 工程刚刚完成了谷歌云 VMware Engine(GCVE)所需的测试,该引擎将被视为官方支持的 Citrix 虚拟化平台。Citrix 尚未完成 GCVE 的任何正式可扩展性测试。也就是说,GCVE 是一项谷歌托管服务,它基于 VMware 的云基金会(VCF)架构提供由 VMware 提供支持的软件定义数据中心(SDDC)。由于 VMware、其客户和合作伙伴多年来一直在基于 VCF 的系统上部署 Citrix,因此已经有大量与 GCVE 直接相关的知识可用。

例如:GCVE 目前在名为 ve1-standard-72 的节点类型上可用。此节点类型有 36 个物理内核(72 个超线程内核)和 768GB RAM。使用服务器操作系统 VDA 和 3 节点 SDDC 配置在 Windows Server 2019 上估算托管共享桌面工作负载时,总共将有 108 个物理内核或 216 个超线程 vCPU。作为参考-我们通常会看到使用具有 4 个 vCPU 配置(2 个物理内核)和足够内存来支持用户工作负载的 Citrix Server OS VDA 实现最高效的可扩展性。在为 VMware 主机预留一些计算和内存资源后,我们预计每个 GCVE 节点可以轻松托管大约 17 个 Citrix VDA 实例,每个实例具有 4 个 vCPU 和 36 GB RAM。

如果您熟悉 Nick Rintalan 的 “5 和 10 规则”,它为本地数据中心提供了单服务器可扩展性指导,那么您会记得他关于每个物理内核大约 10 个 CVAD 会话用户的建议。由于 GCVE 服务器是超线程的,因此 4 个 vCPU 虚拟机为每个 Citrix 会话主机使用 2 个物理内核。对于 CVAD 会话主机应用 10 的规则意味着我们可以预期每个虚拟机约有 20 个用户,工作负载较轻。对于繁重的工作负载,这个数字大约是每台虚拟机的一半或大约 10 个用户。

这些计算用于确定 GCVE 集群中预期的大致用户数量,并且在特定工作负载下会发生变化。我们强烈建议您测试自己的工作负载,并决定哪种配置最适合您的工作负载。

结论

这项研究的结果表明了以下几点:

正如预期的那样,Citrix VDA 的性能往往受到 CPU 的限制,而不是磁盘性能或网络带宽的限制。

发布之时,Google Cloud上提供的最新处理器提供了最佳的最终用户体验(根据我们的知识工作者参考工作量进行衡量)。它们在 N2、N2D 和 C2 实例系列中可用,并利用英特尔的 Cascade Lake 和 AMD 的米兰和罗马处理器。

对于知识工人配置文件,最经济高效的三种实例类型是:

  • N2D-Standard-8 实例类型(采用 AMD Milan 处理器)实现了每个 vCPU 2.875 个用户,是最具成本效益的,按已发布的即用即付定价计算,每用户小时的成本低至 0.0280 美元。
  • N2D-Standard-8 实例类型(使用 AMD Rome 处理器)紧随其后的是每个 vCPU 2.25 个用户,成本低至每小时 0.036 美元。
  • C2-Standard-8 实例类型(使用英特尔 Cascade Lake 处理器)也实现了每个 CPU 2.25 个用户,成本略高,为每用户小时 0.040 美元。

速度更快的处理器是知识型员工工作负载的最佳平台。结果表明,最佳选择是 8 个 vCPU 和 4 个 vCPU 实例大小,而迁移到 16 个 vCPU 实例大小会显著减少每个 vCPU 的预期用户数量。

使用最新的处理器,用于永久性磁盘的存储类型不会对实例的可扩展性产生实质性影响。虽然我们发现磁盘性能类型与使用 N2D 和 C2 实例类型时虚拟机上的预期用户数之间没有关联,但我们确实看到 N1 实例的性能差异很大。

虽然本研究没有进行明确测试,但需要 GPU 的工作负载必须在 N1 实例类型上运行。在需要GPU加速的情况下,利用Skylake处理器和高级SSD永久性磁盘存储可能会产生最佳性能和最高的可扩展性。

与往常一样,请记住,这是用于测试和验证的示例工作负载,可能代表也可能不代表您的工作负载。我们建议您在使用特定架构之前先在 Google Cloud 中测试您的工作负载。您可以利用 Login VSI 的 Login Enterprise 工具来创建自定义工作负载,该工作负载将近似用户的日常活动,并提供可帮助您评估用户体验的 EUX 分数。在系统上记录单个用户的 EUX 分数,然后一次添加一个用户,直到分数降低 0.5,以确定系统中推荐的用户。

特别感谢Login VSI团队与我们密切合作,因为我们使用了预发布的EUX评分算法来评估Google Cloud。

在 Google 云计算引擎上调整 VDA 实例的大小