本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 实例集定制
<a name="fleet-customization"></a>

## 实例集类型
<a name="fleet-type"></a>

创建实例集时，客户必须选择实例集类型。每种实例集类型在优化用户体验、成本和维护开销方面都有不同的优势。无论选择哪种实例集类型，每个选项都支持 Windows 和 Linux 平台类型，以及桌面视图或应用程序视图。

客户现在可以从以下实例集类型中进行选择：
+  **Always-On**— 这种队列类型为用户提供了对其应用程序的即时访问权限。即使没有任何用户流式传输应用程序，您也需要为实例集中所有正在运行的实例付费。
+  **On-Demand**— 选择此队列类型以优化您的流媒体成本。使用按需型实例集，用户开启会话的时间约为一到两分钟。但是，只有在用户连接时才会向您收取流式处理实例费用，而对于实例集中不是流式传输应用程序的每个实例，则需要按小时支付少量费用。
+  **弹性** — 弹性实例集可用于不需要安装且可以从虚拟硬盘 (VHD) 运行的应用程序。Elastic 队列不支持 WorkSpaces 应用程序镜像，也不需要扩展策略。您只需为流会话的持续时间付费。

 

*表 2 — 亚马逊 WorkSpaces 应用程序队列类型*


| 实例集类型 | 何时使用 | 用户体验 |  定价模式 | 注意  | 
| --- | --- | --- | --- | --- | 
|  **Always-On**  | 您的用户在启动会话时需要即时访问应用程序。也许因为您的使用模式是可预测的，并且您可以通过扩缩策略可靠地控制成本，因此您的实例集不会出现明显的容量过剩。 | 即时访问应用程序 | 您需要为实例集中的每个可用实例支付全额费用（无论该实例是否用于会话）。 | 支持自定义映像和扩缩策略。 | 
|  **On-Demand**  | 您必须在实例集中保持大量过剩容量。您希望将环境成本最优化，并且不想为未使用的容量支付全额费用。您的用户可以在启动会话后等待一到两分钟才能访问其应用程序。您使用的实例类型较多。持续运行的实例的每小时费用比已停止的实例费用昂贵得多。 | 用户在启动会话后要等待一到两分钟才能访问其应用程序。 | 您只需为会话处于活动状态的流式传输实例支付全额费用，然后为空闲实例按小时支付少量费用。 | 支持自定义映像和扩缩策略。 | 
|  **弹性**  | 您的应用程序及其依赖项的大小小于 1.5 GB 时。每当用户使用弹性实例集启动会话时，都必须从 Amazon S3 将您的虚拟硬盘 (VHD) 文件下载到会话中。因此，较大的 VHD 文件（即大小超过 1.5 GB）将导致最终用户体验不佳。您的应用程序是可便携的。也就是说，您的应用程序及其所有依赖项可以放置在 VHD 上，然后从 VHD.You 不需要加入域名的流媒体实例启动（Elastic 队列目前不支持加入域名）。您只想为活动会话付费（即您无需为队列中的未使用容量付费）。您的用户可以在启动会话后等待 45 秒或更长时间才能访问他们的应用程序。您希望 AWS 为您管理扩展（无需管理扩展策略）。 | 用户在启动会话后等待 45 秒到 3 分钟才能访问应用程序（等待时间取决于虚拟硬盘的大小）。 | 您只需为流会话的持续时间付费。由于弹性实例集中没有闲置实例的概念，因此对于未使用的实例，您无需支付任何费用。 | 不支持自定义映像（客户提供 VHD 来启动应用程序）或扩缩策略。目前支持 `stream.standard.small` 和 `stream.standard.medium` 实例。如果您的用例需要不同的实例类型，请联系您的 AWS 账户团队。 | 

![显示实例集类型使用案例和要求的图表...](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/best-practices-for-deploying-amazon-appstream-2/images/use-case-and-requirements.png)


## 实例集大小调整
<a name="fleet-sizing"></a>

### 最低容量和计划扩缩
<a name="minimum-capacity-and-scheduled-scaling"></a>

 在调整 WorkSpaces 应用程序群规模时，有几个考虑因素会直接转化为用户体验和成本。为**最小容量**输入的值可确保 WorkSpaces 应用程序实例的数量很少会小于此值。 WorkSpaces 应用程序会话结束后，如果 WorkSpaces 应用程序实例总数小于**最小容量**值，则会启动一个新的队列实例。与往常一样，重要的是要记住一个 WorkSpaces 应用程序实例直接映射到一个用户会话，这会直接影响**最小容**量的值。

 为**最小容量**输入超出预期并发数的值会导致成本增加，但用户体验不会受到影响。值过低可以缩减成本，但如果请求总数超过可用容量，则会影响用户体验。在这种情况下，管理员会发现出现“容量不足”错误。例如，如果一天开始时的预期连接数始终为可预测值，等待 `PendingCapacity` 变成 `AvailableCapacity` 则未能有效利用用户时间。

 可以一开始使用可适应典型非高峰时段的最小容量，然后使用[https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html)可在工作日开始之前有效地重置最小容量。不要忘记创建另一个计划扩缩策略，在非高峰时段恢复为最小容量。有关扩缩策略及其实施方法的更多信息，请参阅本文档中的[*实例集自动扩缩策略*](fleet-auto-scaling-strategies.md)部分。

### 最大容量和服务限额
<a name="maximum-capacity-and-service-quotas"></a>

 设置最大容量看似是一个任意值，但是如果预测和设置得当，则可以优化总资源消耗和成本。输入的值如果高于您的[https://docs.aws.amazon.com/appstream2/latest/developerguide/limits.html](https://docs.aws.amazon.com/appstream2/latest/developerguide/limits.html)，则 AWS 账户 可能看起来是有效的，但是，当 auto scaling 事件尝试将资源扩展到最大容量时，它们将无法启动，因为最大容量值超过了可用的服务配额。确保针对所需的最大容量提出服务限额请求，以确保自动扩缩按照组织预期的那样运行。

 设置最大容量值时的另一个重要考虑因素是成本。有关更多信息，请参阅本文档的[*通过选择实例集类型来优化成本*](cost-optimization.md#optimizing-costs-with-fleet-type-choice)部分。