本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 托管资源自定义
本节将介绍用于配置和管理 Amazon GameLift Servers 基础设施的高级选项，可协助您满足特定的性能、成本和运营要求。具体而言，本节主题将阐述如何自定义 Amazon GameLift Servers 托管式托管资源，以使其充分契合您的游戏及玩家需求。
需要考虑的决策包括：
+ 在何处为玩家部署托管资源？ 游戏延迟是选择实例集地理位置时的主要考量因素，但不同位置还存在其他差异因素，包括资源类型的可用性和成本。
+ 哪些 EC2 实例类型最能支持你的游戏？ 从可用的实例类型中进行选择，以使用计算架构、内存、存储和网络容量的最佳组合。
+ 您需要多大的实例类型？ 根据游戏服务器软件的资源需求（内存和 CPU）和其他因素选择实例类型大小。
+ 您的实例集应使用按需型实例还是竞价型实例？ 考虑您能否利用较低的竞价型实例定价，以及 Amazon GameLift Servers 能否充分降低竞价型实例中断对游戏会话的影响。
+ 您希望游戏服务器软件如何在每个实例集实例上运行？ 运行时配置会告知 Amazon GameLift Servers 要运行的服务器软件及其运行方式。
+ 对于容器实例集，默认配置是否适用于您的游戏？Amazon GameLift Servers 会为您完成容器实例集配置方面的大量优化工作，但您仍可自定义大多数配置设置。
# 为托管式实例集选择计算资源
对于 Amazon GameLift Servers 托管式托管（包括托管式 EC2 和托管容器），该服务会将您的游戏服务器部署到 AWS 云中的计算资源实例集。创建托管式实例集时，您需要配置最适合您游戏的托管资源。本主题讨论了选择和配置游戏托管式实例集时的关键决策点。
**注意**
如果您要同时使用 Anywhere 和 Amazon GameLift Servers 托管式实例集构建混合解决方案，请使用这些主题来设计托管式实例集，以补充您自己的自管理资源。请参阅[为 Amazon GameLift Servers 部署托管实例集](fleets-intro.md)。
**Topics**
+ [地理位置](#gamelift-compute-location)
+ [操作系统](#gamelift-compute-os)
+ [实例类型](#gamelift-compute-instance)
+ [按需型实例和竞价型实例](#gamelift-compute-spot)
+ [服务配额](#gamelift-service-limits)
## 地理位置
考虑一下您计划部署游戏服务器的位置。通常，为提供最佳玩家体验，应将游戏服务器部署在尽可能靠近玩家的位置。对于托Amazon GameLift Servers管主机，您可以选择将游戏服务器放置在任何支持的区域 AWS 区域 和 Local Zones 中。如果您正在构建混合解决方案，请考虑托管式实例集部署如何能够补充您自行管理的 Amazon GameLift Servers Anywhere 实例集的部署位置。
对于大多数开发和测试场景，部署到单一位置即可满足需求。当您为游戏发布及后续运营做准备时，选择跨多个地理位置部署则具有多重优势，包括为广泛的玩家群体提供支持，以及提高游戏托管的整体弹性和可靠性。此外，多位置部署还能加快游戏会话放置速度，并在针对延迟和成本优化放置时提供更多选择，从而提升玩家体验。
有关 Amazon GameLift Servers 支持的位置列表以及关于所有实例集类型的位置的更多信息，请参阅 [Amazon GameLift Servers 服务位置](gamelift-regions.md)。
多位置实例集
单个托管式实例集可以将资源部署到多个位置。您可以针对多位置实例集中的每个独立位置，手动设置容量。
使用多位置实例集的优势：
+ 简化实例集部署和管理：您只需提供游戏服务器软件和实例集配置，然后 Amazon GameLift Servers 会将其部署到多个位置的实例集实例（一次构建，随处部署）。在生产实例集中，您可以查看和管理实例集中的所有位置，而不必管理位于不同区域的多个实例集。
+ 本地区域可用性-如果要使用本地区域，则必须创建多地点舰队，将 AWS 区域 总部位置和本地区域作为远程位置。Local Zones 是它的扩展 AWS 区域 ，可以为有需要的区域和客户提供更低的延迟。您可以将 Local Zones 添加到任何多位置实例集中；无需包括 Local Zones 的父 AWS 区域。
+ 与游戏会话队列兼容：您可以构建包含一个或多个多位置实例集的游戏会话放置队列。此方法使队列在优先选择和确定用于托管新游戏会话的位置时更具灵活性。
+ 高效的资源利用率：开启自动扩缩功能后，Amazon GameLift Servers 可以更好地优化实例集中所有位置的容量扩展。
使用多位置实例集的提示：
+ 查看每个 AWS 区域 或车队的位置数量的配额。请参阅 [Amazon GameLift Servers 服务限额](https://docs.aws.amazon.com/general/latest/gr/gamelift.html#limits_gamelift)。
+ 并非所有实例类型都在所有位置可用。实例类型选择可能有限，具体取决于您选择的位置。Amazon GameLift Servers 控制台提供了有用的工具，可帮助您在位置和实例类型之间找到适当的平衡。
+ 考虑使用 [UDP ping 信标](reference-udp-ping-beacons.md)来收集所有实例集位置的玩家延迟数据。Amazon GameLift Servers 可以使用这些数据来优化游戏会话以实现低延迟，并防止玩家加入延迟过高的会话。这些特殊端点接受 UDP 消息，而不是传统的 ICMP ping 消息，同时提供准确的延迟测量，有助于您选择最佳实例集位置。
## 操作系统
托管式实例集中的所有实例均使用亚马逊机器映像（AMI）进行部署，该映像可为游戏服务器软件提供完整的运行时环境。对于托管式 EC2 实例集，您可以在将游戏服务器生成包上传到 Amazon GameLift Servers 时指定生成包的操作系统。对于托管式容器实例集，您可以在容器组定义中指定操作系统。有关最新 AMI 版本的更多信息，请参阅[Amazon GameLift Servers AMI 版本](reference-ec2-ami-version-history.md)。
AMI 版本会定期更新。创建新实例集时，Amazon GameLift Servers 会分配您为游戏生成包选择的 AMI 的最新可用版本。部署在该实例集中的所有实例都使用相同的版本。要使您的 AMI 版本与最新的安全和软件更新保持同步，您需要定期更换实例集。作为最佳实践，我们建议每 30 天更换一次托管式实例集，以便为游戏服务器维护运行时环境。有关指南，请参阅[Amazon GameLift Servers 的安全最佳实践](security-best-practices.md)。
## 实例类型
托管式实例集的实例类型决定了为所有实例集部署的硬件类型，并且实例类型通常有多种规格可供选择。所有 Amazon GameLift Servers 托管式实例集均使用 Amazon EC2 实例，并支持多种实例类型，这些类型提供了计算能力、内存、存储和网络性能的不同组合。实例类型的可用性因您选择的位置而异。
Amazon GameLift Servers 控制台提供了有用的工具，可帮助您找到适合游戏生成包和部署位置的正确实例类型。对于托管式容器实例集，控制台还提供有关游戏的 CPU 功率和内存要求的指导。
在为您的游戏选择可用实例类型时，请考虑：
+ 游戏服务器的计算架构：x64 或 Arm（AWS Graviton）。
**注意**
Graviton Arm 实例需要一个针对 Linux AMI 的服务器生成包。C\$1\$1 和 C\$1 需要服务器软件开发工具包 5.1.1 或更高版本。Go 需要服务器软件开发工具包 5.0 或更高版本。这些实例不 out-of-the-box支持在亚马逊 Linux 2023 (AL2023) 或亚马逊 Linux 2 (AL2) 上安装 Mono。
+ 您的游戏服务器构建的计算、内存和存储要求。
+ 您的实例类型的大小。除了满足游戏服务器软件可执行文件的要求外，更大的实例类型还可以在每个实例上运行多个游戏服务器进程 and/or 容器。需要考虑的因素包括成本（运行少量大型实例与运行多个小型实例相比，哪种方案更经济）。还要考虑在实例集扩展事件期间，或关闭运行状况不佳的实例时，实例的增减可能会对游戏会话容量产生何种影响。如果每个实例同时运行多个游戏服务器进程，则添加或移除实例可能会严重影响游戏托管容量。
有关实例类型的更多信息，请参阅 [Amazon EC2 实例类型](https://aws.amazon.com/ec2/instance-types/)。
## 按需型实例和竞价型实例
Amazon EC2 按需型实例和竞价型实例提供相同的硬件和性能，但它们在可用性和成本上有所不同。
**按需型实例**
您始终可以在需要按需型实例时获取它并将它保存任意长的时间。按需型实例具有固定成本，意味着您只需为使用这些实例的时间量付费。无长期承诺。
**竞价型实例**
通过利用未使用的 AWS 计算容量，竞价型实例可以为按需实例提供经济实惠的替代方案。竞价型实例的价格根据每个地点每种实例类型的供需情况而波动。 AWS 只要竞价型实例需要恢复容量，就可以在两分钟通知的情况下回收竞价型实例，并且在回收的实例上正在运行的游戏会话会被中断。
Amazon GameLift Servers 提供了多种工具，可帮助降低竞价型实例中断对您游戏会话造成影响的可能性。竞价可行性算法会跟踪实例类型的历史数据，以预测中断风险何时达到临界点，并避免在该类型的竞价型实例上放置新的游戏会话。如果确实发生了中断，您的游戏服务器可以使用通知正常结束玩家的游戏会话。
使用竞价型实例集托管游戏时，必须通过队列来放置游戏会话。队列可以根据竞价型实例集的可行性、成本和其他因素来确定游戏会话放置的优先级。有关如何利用竞价型实例托管游戏服务器的更多信息，请参阅以下主题：
+ [借助竞价型实例集降低游戏托管成本](fleets-spot.md)
+ [为竞价型实例构建队列](spot-tasks.md)
## 服务配额
您可以使用以下工具查看 Amazon GameLift Servers 的默认服务配额和 AWS 账户 的当前配额状态：
+ 有关 Amazon GameLift Servers 的通用服务配额信息，请参阅《AWS 一般参考》**中的 [Amazon GameLift Servers 端点和配额](https://docs.aws.amazon.com/general/latest/gr/gamelift.html)。
+ 要查看账户每个位置的可用实例类型列表，请打开 Amazon GameLift Servers 控制台的[服务配额](https://console.aws.amazon.com/gamelift/service-quotas)页面。该页面还会显示您的账户在每个位置的每种实例类型的当前使用情况。
+ 要查看您的账户当前每个区域的实例类型配额列表，请运行 AWS Command Line Interface (AWS CLI) 命令[https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/describe-ec2-instance-limits.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/describe-ec2-instance-limits.html)。此命令返回您在默认区域（或您指定的其他区域）中拥有的活动实例数量。
准备启动游戏时，请在[Amazon GameLift Servers主机](https://console.aws.amazon.com/gamelift/)中填写发布问卷。Amazon GameLift Servers 团队使用发布问卷来确定您的游戏的正确配额和限制。
# 自定义 Amazon GameLift Servers 容器实例集
本节主题介绍了 Amazon GameLift Servers 托管式容器的一些可选功能。您可以选择使用其中任意一项或全部功能。
**Topics**
+ [设置资源限制](#containers-design-fleet-limits)
+ [了解容器舰队的内存分配](#containers-design-fleet-memory-allocation)
+ [配置 NVMe 云端硬盘访问权限](#containers-design-fleet-nvme)
+ [指定必备容器](#containers-design-fleet-essential)
+ [配置网络连接](#containers-custom-network)
+ [为容器设置运行状况检查](#containers-design-fleet-health)
+ [设置容器依赖关系](#containers-design-fleet-dependencies)
+ [配置容器实例集](#containers-design-fleet-config)
## 设置资源限制
对于每个容器组，您可以确定容器组运行其软件所需的内存和计算能力。Amazon GameLift Servers 依靠这些信息来管理整个容器组的资源。它还使用这些信息来计算实例集映像可以容纳的游戏服务器容器组数量。此外，您也可以为各个容器设置限制。
您可以为容器组设置内存和计算能力的最大限制。默认情况下，这些资源由组内的所有容器共享。您可以通过为单个容器设置限制来进一步自定义资源管理。
**为单个容器设置可选限制**
通过设置容器特定的资源限制，您可以更好地控制各个容器如何使用组内资源。如果未设置特定于容器的限制，则组内所有容器将共享组资源。这种共享方式能够更灵活地按需分配资源，但也可能导致进程间资源竞争，进而引发容器故障。
可为任何容器设置以下任一 `ContainerDefinition` 属性。
+ `MemoryHardLimitMebibytes`：为容器设置最大内存限制。如果容器超过此限制，则会重启。
+ `Vcpu` limit：保留最低数量的 vCPU 资源供容器专用。容器始终拥有该预留资源。如果有其他资源可用，其使用量可随时超过此最低限额。（1024 个 CPU 单位相当于 1 个 vCPU。）
**为容器组设置总资源限制**
如果您为单个容器设置了限制，则可能需要修改容器组所需的内存和 vCPU 资源。目标是分配足够的资源来优化游戏服务器性能。Amazon GameLift Servers 使用这些限制来计算如何在实例集实例上打包游戏服务器容器组。此外，在为容器实例集选择实例类型时，也需要参考这些限制。
计算容器组所需的总内存和 vCPU。请考虑以下事项：
+ 容器组内所有容器运行的全部进程有哪些？ 将这些过程所需的资源累加起来。注意任何特定于容器的限制。
+ 您计划在每个容器组中运行多少个并发游戏服务器进程？ 您可以在游戏服务器容器映像中确定这一数量。
根据您对容器组需求的估计，设置以下 `ContainerGroupDefinition` 属性：
+ `TotalMemoryLimitMebibytes`：为容器组设置最大内存限制。组中的所有容器共享分配的内存。如果已设置单个容器限制，则总内存限制必须等于或大于容器特定的最高内存限制。
+ `TotalVcpuLimit`：为容器组设置最大 vCPU 限制。组中的所有容器共享分配的 CPU 资源。如果已设置单个容器限制，则总 CPU 限制必须等于或大于所有容器特定 CPU 限制的总和。作为最佳实践，建议将此值设置为容器 CPU 限制之和的两倍。
**示例方案**
假设我们要定义一个包含以下三个容器的游戏服务器容器组：
+ 容器 A 为游戏服务器容器。一台游戏服务器的资源需求预估为 512 MiB 内存和 1024 个 CPU 单位。我们计划让容器运行 1 个服务器进程。由于此容器运行最关键的软件，我们没有设置内存限制或 vCPU 预留限制。
+ 容器 B 是一个支持容器，其资源需求估计为 1024 MiB 内存和 1536 个 CPU 单位。我们将内存限制设置为 2048 MiB，CPU 预留限制为 1024 个 CPU 单位。
+ 容器 C 是另一个支持容器。我们将硬性内存限制设置为 512 MiB，将 CPU 预留限制设置为 512 个 CPU 单位。
使用这些信息，我们为容器组设置了以下总限制：
+ 总内存限制：7680 MiB。此值超过了最高内存限制（1024 MiB）。
+ CPU 总限制：13312 个 CPU 单位。此值超过了 CPU 限制的总和（1024\$1512 CPU）。
## 了解容器舰队的内存分配
在队列实例上Amazon GameLift Servers部署容器组时，并非该实例的所有内存都可用于您的容器。 Amazon GameLift Servers为操作系统、Amazon ECS 代理和其他支持服务保留一部分实例内存。预留内存量因实例类型的总内存而异。了解这一开销有助于您配置容器组定义以充分利用可用资源。
### 内存开销公式
Amazon GameLift Servers使用以下步骤计算容器组的可用内存：
1. **确定内存缓冲区百分比。** Amazon GameLift Servers根据以下等级预留实例总内存的一定百分比：
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/gameliftservers/latest/developerguide/containers-design-fleet.html)
1. **计算可用内存。**从实例总内存中减去预留内存：
`AvailableMemory = InstanceMemory - round(InstanceMemory × BufferPercentage)`
1. **减去每个实例的容器组内存。**如果您的队列使用每个实例的容器组，请`TotalMemoryLimitMebibytes`从可用内存中减去该容器组。每个队列实例上运行一个每个实例的容器组。
`AvailableMemory = AvailableMemory - PerInstanceCGD.TotalMemoryLimitMebibytes`
1. **考虑日志路由器开销。**如果队列启用了日志记录，则每个游戏服务器容器组为日志路由器额外Amazon GameLift Servers预留 50 MiB。
1. **计算最大游戏服务器容器组。**按内存容纳在实例上的游戏服务器容器组的最大数量为：
`MaxGroupsByMemory = floor(AvailableMemory / (GameServerCGD.TotalMemoryLimitMebibytes + LogRouterMemory))`
如果启用了日志记录，则`LogRouterMemory`为 50 MiB；如果禁用了日志记录，则为 0。
**注意**
内存只是决定一个实例上可容纳多少个游戏服务器容器组的因素之一。 Amazon GameLift Servers还会考虑 vCPU 容量和可用连接端口，并使用所有三种计算中的最低值。
### 内存计算示例
假设队列使用启用了日志`c5.xlarge`记录的实例（总内存 8,192 MiB）：
1. 实例内存为 8,192 MiB，属于 5,000—9,999 层（缓冲区为 6%）
1. 预留内存 = 回合 (8,192 × 0.06) = 492 MiB
1. 可用内存 = 8,192-492 = 7,700 MiB
1. 如果使用的每实例容器组为 512：可用内存 = 7,700-512 = 7,188 MiB `TotalMemoryLimitMebibytes`
1. 如果每个游戏服务器容器组有 `TotalMemoryLimitMebibytes` 1,024 个： MaxGroupsByMemory = 下限 (7,188/(1,024 \$1 50)) = 下限 (7,188/1,074) = 6
### 按实例类型划分的可用内存
下表显示了常用实例类型的总内存和可用内存（Amazon GameLift Servers缓冲区之后）。配置容器组定义时，请使用这些值作为起点。*可用内存*列显示实例上所有容器组的可用内存，然后再减去每个实例的容器组或日志路由器的开销。
| 实例类型 | 总内存 (MiB) | 缓冲区百分比 | 可用内存 (MiB) |
| --- | --- | --- | --- |
| c5.large | 4,096 | 8% | 3,768 |
| c5.xlarge | 8192 | 6% | 7,700 |
| c5.2xlarge | 16,384 | 5% | 15,565 |
| c5.4xlarge | 32,768 | 5% | 31,130 |
| c5.9xlarge | 73,728 | 5% | 70,042 |
| c5.12xlarge | 98,304 | 4% | 94,372 |
| c5.18xlarge | 147,456 | 4% | 141,558 |
| c5.24xlarge | 196,608 | 4% | 188,744 |
| m5.large | 8192 | 6% | 7,700 |
| m5.xlarge | 16,384 | 5% | 15,565 |
| m5.2xlarge | 32,768 | 5% | 31,130 |
| m5.4xlarge | 65,536 | 5% | 62,259 |
| m5.8xlarge | 131,072 | 4% | 125,829 |
| m5.12xlarge | 196,608 | 4% | 188,744 |
| r5.large | 16,384 | 5% | 15,565 |
| r5.xlarge | 32,768 | 5% | 31,130 |
| r5.2xlarge | 65,536 | 5% | 62,259 |
| r5.4xlarge | 131,072 | 4% | 125,829 |
| c6i.large | 4,096 | 8% | 3,768 |
| c6i.xlarge | 8192 | 6% | 7,700 |
| c6i.2xlarge | 16,384 | 5% | 15,565 |
| c6i.4xlarge | 32,768 | 5% | 31,130 |
| c6i.8xlarge | 65,536 | 5% | 62,259 |
| c7i.large | 4,096 | 8% | 3,768 |
| c7i.xlarge | 8192 | 6% | 7,700 |
| c7i.2xlarge | 16,384 | 5% | 15,565 |
| c7i.4xlarge | 32,768 | 5% | 31,130 |
| c7i.8xlarge | 65,536 | 5% | 62,259 |
| m7i.large | 8192 | 6% | 7,700 |
| m7i.xlarge | 16,384 | 5% | 15,565 |
| m7i.2xlarge | 32,768 | 5% | 31,130 |
| m7i.4xlarge | 65,536 | 5% | 62,259 |
| m7i.8xlarge | 131,072 | 4% | 125,829 |
| m7i.12xlarge | 196,608 | 4% | 188,744 |
| r7i.large | 16,384 | 5% | 15,565 |
| r7i.xlarge | 32,768 | 5% | 31,130 |
| r7i.2xlarge | 65,536 | 5% | 62,259 |
| r7i.4xlarge | 131,072 | 4% | 125,829 |
对于此处未列出的实例类型，您可以使用上述公式计算可用内存。查看 [Amazon EC2 实例类型文档](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-instance-type-specifications.html)，了解所选实例类型的总内存。
## 配置 NVMe 云端硬盘访问权限
在 d 型实例上， NVMe 驱动器会在主机启动期间自动装载到`/data`目录中。要使容器能够访问 SSD 存储，请设置以下`ContainerGroupDefinition`属性`MountPoints`：
+ `InstancePath`— 设置为`/data`以引用主机实例上自动装载的 NVMe 驱动器。
+ `AccessLevel`— 根据容器的需求选择适当的访问级别（例如 READ\$1ONLY 或 READ\$1WRITE）。
+ `ContainerPath`—（可选）指定将实例路径挂载到容器内的路径。如果未指定，则默认为实例路径。
有关挂载点的更多信息，请参阅 Amazon GameLift 服务器 API 参考[ContainerMountPoint](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_ContainerMountPoint.html)中的。
## 指定必备容器
对于每个实例容器组，需将每个容器指定为必备容器或非必备容器。每个实例容器组必须具有至少一个必备支持容器。必备容器负责容器组的关键工作，需始终保持运行状态。若其发生故障，整个容器组将重启。
将每个容器的 `ContainerDefinition` 属性 `Essential` 设置为 true 或 false。
## 配置网络连接
您可以自定义网络访问权限以允许外部流量连接到容器实例集中的任何容器。例如，您必须与运行游戏服务器进程的容器建立网络连接，以便游戏客户端能够接入并参与游戏。游戏客户端使用端口和 IP 地址连接到游戏服务器。
在容器实例集中，客户端与服务器之间并非直接连接。在内部，容器中的进程会监听*容器端口*。在外部，传入流量使用*连接端口*连接到实例集实例。Amazon GameLift Servers 维护内部容器端口和面向外部的连接端口之间的映射，以便将传入流量路由到实例上的正确进程。
Amazon GameLift Servers 为您的网络连接提供了额外一层控制。每个容器实例集都有*入站权限*设置，允许您控制对每个面向外部的连接端口的访问。例如，您可以移除所有连接端口的权限，以关闭对实例集容器的所有访问权限。
您可以更新实例集的入站权限、连接端口和容器端口。
**警告**
如果您提供自定义 InstanceConnectionPortRange 或 InstanceInboundPermissions，则Amazon GameLift Servers将不再为您的队列管理任一值。您必须同时设置这两个字段，以避免出现未定义行为。
**设置容器端口范围**
容器端口范围需作为每个容器定义的一部分进行配置。这是容器组定义的必填参数。您需要配置足够的端口，以容纳所有需要外部访问的并发运行的进程。有些容器不需要任何端口。
运行游戏服务器的游戏服务器容器需要一个端口，用于每个并发运行的游戏服务器进程。游戏服务器进程会监听分配的端口并将其报告给 Amazon GameLift Servers。
**设置连接端口范围**
为容器实例集配置一组连接端口。连接端口提供对运行容器的实例集实例的外部访问权限。Amazon GameLift Servers 会根据需要分配连接端口，并将其映射到容器端口。
默认情况下，Amazon GameLift Servers 会计算所有容器组所需的端口数，并设置相应的端口范围以满足需求。我们强烈建议您使用 Amazon GameLift Servers 的计算值，该值会在您部署容器组定义更新时自动更新。如果您确实需要自定义连接端口范围，请使用以下指南。
创建容器队列时，请定义连接端口范围（请参阅[ ContainerFleet:InstanceConnectionPortRange](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_ContainerFleet.html)）。确保该范围有足够的端口，可以映射到在实例集中两个容器组内所有容器中定义的每个容器端口。要计算所需的最小连接端口数，请使用以下公式：
`[Total number of container ports defined for containers in the game server container group] * [Number of game server container groups per instance] + [Total number of container ports defined for containers in the per-instance container group]`
最佳实践是，将最小连接端口数量翻倍。
连接端口的数量可能会限制每个实例的游戏服务器容器组的数量。如果实例集的连接端口仅足以满足每个实例部署一个游戏服务器容器组的需求，则即使实例的计算资源足以承载多个游戏服务器容器组，Amazon GameLift Servers 仍只会部署一个游戏服务器容器组。
**设置入站权限**
入站权限通过指定允许传入流量访问的连接端口，来控制对容器实例集的外部访问。您可以使用此设置，根据需要开启和关闭实例集的网络访问权限。
默认情况下，Amazon GameLift Servers 会计算所有容器组所需的端口数，并设置相应的端口范围以满足需求。我们强烈建议您使用 Amazon GameLift Servers 的计算值，该值会在您部署容器组定义更新时自动更新。如果您确实需要自定义连接端口范围，请使用以下指南。
创建容器队列时，请定义一组入站权限（请参阅[ ContainerFleet:InstanceInboundPermissions](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_ContainerFleet.html)）。入站许可端口应与实例集的连接端口范围相匹配。
由于容器端口是从中随机选择的 InstanceConnectionPortRange，因此为了保证可以建立会话连接，因此中的所有端口都 InstanceConnectionPortRange 应被中的端口覆盖 InstanceInboundPermissions
**示例方案**
此示例说明了如何设置所有三个网络连接属性。
+ 我们实例集的游戏服务器容器组有 1 个容器，其中运行 1 个游戏服务器进程。
在游戏服务器容器组定义中，我们按如下方式设置该容器的 `PortConfiguration` 参数：
```
"PortConfiguration": {
"ContainerPortRanges": [ { "FromPort": 10, "ToPort": 20, "Protocol": "TCP"} ] }
```
+ 我们的实例集还有一个每个实例容器组，其中包含 1 个容器。它有 1 个需要网络访问的进程。在每个实例的容器定义中，我们按如下方式设置此容器的 `PortConfiguration` 参数：
```
"PortConfiguration": {
"ContainerPortRanges": [ { "FromPort": 25, "ToPort": 25, "Protocol": "TCP"} ] }
```
+ 我们的实例集为每个实例集实例配置 20 个游戏服务器容器组。有了这些信息，我们可以使用以下公式来计算需要的连接端口数：
+ 最少：**21 个端口** [1 个游戏服务器容器端口 \$1 每个实例 20 个游戏服务器容器组 \$1 1 个每个实例容器端口]
+ 最佳实践：**42 个端口** [最少端口 \$1 2]
在创建容器实例集时，我们按如下方式设置 `InstanceConnectionPortRange` 参数：
```
"InstanceConnectionPortRange": { "FromPort": 1010, "ToPort": 1071 }
```
+ 我们希望允许访问所有可用的连接端口。在创建容器实例集时，我们按如下方式设置 `InstanceInboundPermissions` 参数：
```
"InstanceInboundPermissions": [
{"FromPort": 1010, "ToPort": 1071, "IpRange": "10.24.34.0/23", "Protocol": "TCP"} ]
```
## 为容器设置运行状况检查
如果容器遇到终端故障并停止运行，它会自动重启。如果容器标记为必备容器，它会提示整个容器组重新启动。
所有游戏服务器容器都自动被视为是必备容器。可以将支持容器指定为必备容器，但它们需要有报告运行状况的机制。您也可以为非必备支持容器设置运行状况检查。
您可以定义其他自定义标准来衡量容器运行状况，并使用运行状况检查来测试该标准。要设置容器运行状况检查，可以在 Docker 容器映像或容器定义中对其进行定义。如果您在容器定义中设置了运行状况检查，它将覆盖容器映像中的所有设置。
为容器运行状况检查设置以下 `SupportContainerDefinition` 属性：
+ `Command`：提供一个命令来检查容器运行状况的某些方面。您可以决定使用什么标准来衡量运行状况。该命令的退出值必须为 1（不正常）或 0（正常）。
+ `StartPeriod`：指定在开始统计运行状况检查失败次数前的初始延迟时间。此延迟为容器提供启动内部进程的时间。
+ `Interval`：决定执行运行状况检查命令的频率。您希望以多快的速度检测和解决容器故障？
+ `Timeout`：决定在重试运行状况检查命令之前等待成功或失败的时间。运行状况检查命令需要多长时间才能完成？
+ `Retries`：在判定为失败前，运行状况检查命令应重试多少次？
## 设置容器依赖关系
在每个容器组中，您可以根据容器状态设置容器之间的依赖关系。依赖关系会根据另一容器的状态，影响依赖容器的启动或关闭时机。
依赖关系的一个关键使用案例是为容器组创建启动和关闭序列。
例如，您可能希望容器 A 先启动并成功完成，然后再启动容器 B 和 C。要实现这一点，首先要在容器 A 上为容器 B 创建一个依赖关系，条件是容器 A 必须成功完成。然后在容器 A 上为容器 C 创建具有相同条件的依赖关系。启动顺序与关机顺序相反。
## 配置容器实例集
在创建容器实例集时，请考虑以下决策点。这些要点大多取决于容器架构和配置。
**确定要部署实例集的位置**
通常，您应将实例集部署在靠近玩家的地理位置，以最大限度地减少延迟。您可以将您的集装箱舰队部署到任何 AWS 区域 Amazon GameLift Servers支持的集装箱舰队。如果您想将同一台游戏服务器部署到其他地理位置，则可以将远程位置添加到队列中，包括 AWS 区域 和 Local Zones。对于多位置实例集，您可以单独调整每个实例集位置的容量。有关支持的实例集位置的更多信息，请参阅[Amazon GameLift Servers 服务位置](gamelift-regions.md)。
建议使用 [UDP ping 信标](reference-udp-ping-beacons.md)来收集不同地理位置的网络延迟数据，以预测玩家设备和潜在实例集位置之间的延迟。这些特殊端点接受 UDP 消息，而不是传统的 ICMP ping 消息，同时提供准确的延迟测量，有助于您选择最佳实例集位置。
**为实例集选择实例类型和规格**
Amazon GameLift Servers 支持多种 Amazon EC2 实例类型，所有这些类型都可用于容器实例集。实例类型的可用性和价格因位置而异。您可以在 Amazon GameLift Servers 控制台（在**“资源”、“实例”和“服务配额**”下）中查看按位置筛选的支持实例类型列表。
选择实例类型时，首先要考虑实例系列。不同实例系列提供不同的 CPU、内存、存储和网络功能组合。了解有关 [EC2 实例系列](https://aws.amazon.com/ec2/instance-types/)的更多信息。每个实例系列下均提供多种实例规格供您选择。选择实例规格时，需考虑以下问题：
+ 支持您的工作负载所需的最小实例规格是什么？ 利用该信息排除所有规格过小的实例类型。
+ 哪些实例规格适合您的容器架构？ 理想情况下，应选择能够容纳多个游戏服务器容器组副本且资源浪费最少的规格。
+ 哪种扩缩粒度适合您的游戏？ 扩缩实例集容量涉及添加或删除实例，每个实例都代表托管特定数量的游戏会话的能力。需考虑每次添加或移除实例时希望调整的容量大小。如果玩家需求每分钟波动有数千之多，则使用可承载数百或数千个游戏会话的超大型实例可能更为合理；相反，若需要更精细的扩缩控制，则可选择小型实例类型。
+ 是否可通过规格选择节省成本？ 部分实例类型的价格可能因地区可用性不同而存在差异，您可据此寻找成本优化空间。
**设置其他可选实例集设置**
在配置容器实例集时，可以使用以下可选功能：
+ 设置游戏服务器以访问其他 AWS 资源。请参阅[将您的Amazon GameLift Servers托管游戏服务器连接到其他 AWS 资源](gamelift-sdk-server-resources.md)。
+ 保护存在活跃玩家的游戏会话，防止在缩减事件期间过早终止。
+ 限制单个玩家在有限的时间范围内可在实例集上创建的游戏会话数。
# 借助竞价型实例集降低游戏托管成本
使用 Amazon GameLift Servers 托管式托管服务托管多人游戏服务器时，竞价型实例可作为按需型实例的高性价比替代方案。竞价定价模式提供与按需型定价模式相同的硬件配置和性能表现，但可节省大量成本（高达 70-90%）。但是，它们有一个限制：当 AWS 需要恢复容量时，它可以通过两分钟的中断通知回收这些实例。
Amazon GameLift Servers 降低了游戏服务器托管中断的风险。Amazon GameLift Servers 会预测各类竞价型实例的中断概率，避免在高风险实例上部署游戏会话。如果发生罕见的中断情况，您可借助中断通知为玩家平稳结束当前游戏会话。
## Amazon GameLift Servers 如何与竞价型实例集协同工作
为游戏托管设置竞价型实例集后，Amazon GameLift Servers 会持续评估竞价型实例集中实例类型和位置，以确定游戏托管的可行性。
+ 竞价型实例可行性算法会按位置分析竞价型实例类型的近期可用性模式和历史中断率。
+ 根据此分析，Amazon GameLift Servers 会识别出游戏会话中断风险不可接受的竞价型实例类型和位置。它将执行以下操作：
+ 将该实例类型和位置的组合标记为暂时不可行。
+ 新增游戏会话时不再考虑这些不可行的竞价型实例集位置，确保游戏会话仅部署在中断风险低、托管稳定性高的竞价型实例集位置。
+ 即使 AWS 未主动回收资源，也会逐步下线该竞价型实例集位置的既有实例，避免为无法用于游戏托管的实例付费。如果开启游戏会话保护，实例仅在当前活跃游戏会话结束后才会关闭。
+ Amazon GameLift Servers 会持续重新评估您的竞价型实例集中实例类型和位置，以确定游戏托管的可行性。当历史数据更新显示某类曾不可行的实例类型恢复可行时，您可重新纵向扩展该竞价型实例集，Amazon GameLift Servers 也会恢复在该类型实例上部署游戏会话。
## 设计注意事项
在设计使用竞价型实例集的解决方案时，需考量以下问题：
+ **评估游戏会话时长**：游戏会话的平均时长会影响竞价型实例在游戏中的表现情况。游戏会话时长较短时，快速周转机制可确保游戏会话始终运行在基于最新历史数据判定的可行实例类型上。而时长较长的游戏会话会持续运行在初始实例类型上，不再评估近期可行性数据，随着时间推移面临更高的中断风险。
+ **评估实例类型可用性**：并非所有实例集位置都提供全类型的竞价型实例。为竞价型实例集选择实例类型时，可使用 Amazon GameLift Servers 控制台实例集创建工具来帮助您在所需位置找到竞价型实例类型。使用此工具，您可以选择实例集位置，然后查看这些位置的实例类型可用性。
+ **创建多位置竞价型实例集**：您可以创建具有多个位置的竞价型实例集。单个多地点 Spot 队列将具有相同实例类型的实例部署到多个 AWS 区域 或 Local Zones。竞价型实例可行性算法根据实例类型和位置综合评估可行性。如果某个竞价型实例集位置被评估为不可行，则它不会影响实例集中的其他位置，这些位置仍可正常托管游戏会话。
+ **创建具有竞价型实例集多样性的队列**：如果您使用竞价型实例集托管游戏，则需设置游戏会话放置队列。队列会针对每个新游戏会话请求查找可用游戏托管资源并选择最优方案。针对竞价型实例集，建议队列支持跨多个实例集搜索（覆盖不同位置和实例类型），且至少包含一个按需型实例集作为备份容量。设计完善的多实例集队列可提供多样化放置选项，能有效抵御中断、性能下降及服务中断等风险。有关为竞价型实例设计队列的更多指导，请参阅[为竞价型实例构建队列](spot-tasks.md)。
+ **平移处理中断**：设置游戏服务器，以最大限度地降低竞价型实例中断对玩家的影响。 AWS 回收竞价型实例时，使用服务器 SDK 回调函数`onProcessTerminate()`将终止通知Amazon GameLift Servers传递给所有受影响的服务器进程。游戏需实现该回调函数，以平稳结束游戏会话。有关更多信息，请参阅 [回应服务器进程关闭通知](gamelift-sdk-server-api.md#gamelift-sdk-server-terminate)。
**注意**
AWS 会尽一切努力在回收实例之前提供通知，但有可能在警告到来之前 AWS 收回竞价型实例。您还需配置游戏服务器以应对突发中断情况。
+ **为备份实例集配置自动扩缩，保障竞价型实例中断期间的服务连续性。**目标跟踪型自动扩缩可保持容量缓冲并根据需求自动扩展。借助自动扩缩，备份实例集（竞价型或按需型）会在收到的游戏会话请求量增加时，自动开始提升容量。
当竞价型实例集判定为不可行时，可借助自定义扩展机制，利用队列及实例集的可用指标触发备份实例集的快速横向扩展，以迅速补充丢失的容量。可通过 `FirstChoiceOutOfCapacity`、`FirstChoiceNotViable` 和 `PercentAvailableGameSessions` 等指标检测竞价型实例集的不可行状态。通过分析近期 `PlacementsStarted` 指标数据预估替换容量需求。待备份实例集扩展至满足即时需求后，即可切换回常规自动扩缩模式。
+ **与 FlexMatch 集成**：如果您的解决方案使用 FlexMatch 对战构建器，则对竞价型实例集无特殊要求。您可将对战构建器配置为使用含竞价型实例集的队列。Amazon GameLift Servers 会自动优先处理竞价型实例集和按需型实例集间的对战部署，包括新游戏会话部署及现有游戏会话中空玩家位置的回填操作。
# 在托管式 Amazon GameLift Servers 上优化游戏服务器运行时配置
您可以设置托管 EC2 实例集的运行时配置，以便对每个实例运行多个游戏服务器进程。这样可以更有效地使用您的托管资源。
## 实例集如何管理多个进程
Amazon GameLift Servers 使用实例集的运行时配置来确定要在每个实例上运行的进程的类型和数量。运行时配置至少包含一个代表一个游戏服务器可执行文件的服务器进程配置。您可以定义其他服务器进程配置，以运行与您的游戏相关的其他类型的进程。每个服务器进程配置都包含以下信息：
+ 游戏构建中可执行文件的文件名和路径。
+ （可选）要在启动时传递给进程的参数。
+ 要同时运行的进程的数量。
当实例集中的实例激活时，它会启动在运行时配置中定义的服务器进程。对于多个进程，Amazon GameLift Servers 会错开每个进程的启动。服务器进程具有有限的生命周期。当它们结束时，Amazon GameLift Servers 会启动新的进程，以保持运行时配置中定义的服务器进程的数量和类型。
您可以随时通过添加、更改或删除服务器进程配置来更改运行时配置。每个实例都会定期检查对实例集运行时配置的更新，以实施更改。以下介绍 Amazon GameLift Servers 如何采纳运行时配置更改：
1. 该实例向 Amazon GameLift Servers 发送请求以获取最新版本的运行时配置。
1. 该实例将其活动进程与最新的运行时配置进行比较，然后执行以下操作：
+ 如果更新的运行时配置删除了某个服务器进程类型，此类型的活动服务器进程将继续运行直到结束。该实例不会取代这些服务器进程。
+ 如果更新的运行时配置减少了某个服务器进程类型的并发进程数，此类型的多余服务器进程将继续运行直到结束。该实例不会取代这些多余服务器进程。
+ 如果更新的运行时配置添加了新的服务器进程类型或增加了现有类型的并发进程，该实例将启动新的服务器进程，直至达到 Amazon GameLift Servers 的上限。在这种情况下，该实例在现有进程结束时启动新的服务器进程。
## 针对多个进程优化实例集
要在实例集上使用多个进程，请执行以下操作：
+ [创建生成包](gamelift-build-intro.md)，其中包含您要部署到实例集的游戏服务器可执行文件，然后将生成包上传到 Amazon GameLift Servers。生成包中的所有游戏服务器都必须在同一个平台上运行并使用 Amazon GameLift Servers 的服务器软件开发工具包。
+ 使用一个或多个服务器进程配置和多个并发进程创建运行时配置。
+ 将游戏客户端与 AWS SDK 版本 2016-08-04 或更高版本集成。
要优化实例集性能，建议您执行以下操作：
+ 处理服务器进程关闭方案，以确保 Amazon GameLift Servers 可以高效率地回收进程。例如：
+ 向调用服务器 API `ProcessEnding()` 的游戏服务器代码添加关闭程序。
+ 在您的游戏服务器代码中实现回调函数 `OnProcessTerminate()` 以处理来自 Amazon GameLift Servers 的终止请求。
+ 确保 Amazon GameLift Servers 已关闭并重新启动运行状况不正常的服务器进程。您可以通过在游戏服务器代码中实现 `OnHealthCheck()` 回调函数来将该运行状况回报给 Amazon GameLift Servers。Amazon GameLift Servers 自动关闭连续三次均报告为运行状况不正常的服务器进程。如果不实现 `OnHealthCheck()`，Amazon GameLift Servers 会假定服务器进程正常运行，除非该进程无法响应通信。
## 选择每个实例的进程数
在决定要在实例上运行的并发进程数时，需要记住以下内容：
+ Amazon GameLift Servers 限制每个实例的[最大并发进程数](https://docs.aws.amazon.com/general/latest/gr/gamelift.html#limits_gamelift)。实例集服务器进程配置的所有并发进程的总和不能超过此限额。
+ 为维持可接受的性能水平，Amazon EC2 实例类型可能会限制可并发运行的进程数。测试游戏的不同配置以找出您首选实例类型的合适进程数。
+ Amazon GameLift Servers 运行的并发进程数不会超过配置的总数。这意味着从以前的运行时配置到新配置的过渡可能会逐渐发生。
# 使用 Amazon GameLift Servers 代理
Amazon GameLift Servers 代理负责监督 Amazon GameLift Servers 实例集上游戏服务器进程的运行。该代理被部署到实例集中的每个计算上，为计算提供自动化进程管理、托管管理和日志记录。要使用该代理，必须将游戏服务器生成包与 Amazon GameLift Servers 服务器 SDK 5.x 或更高版本集成。
Amazon GameLift Servers 代理可从外部提供给不是托管式 EC2 实例集的 Amazon GameLift Servers 实例集使用。（托管式 EC2 实例集会自动处理该代理的任务。） 您可以选择在有或没有该代理的情况下运行 Amazon GameLift Servers 实例集，包括 Anywhere 实例集。如果没有该代理，您必须提供完成所需任务的替代解决方案。
部署到计算时，应在启动任何游戏服务器进程之前启动 Amazon GameLift Servers 代理。启动时，该代理将完成以下任务：
+ 使用 [RegisterCompute](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_RegisterCompute.html) API 将该计算资源注册到 Amazon GameLift Servers Anywhere 实例集。
+ 调用 [GetComputeAuthToken](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_GetComputeAuthToken.html) API 以获取授权令牌，并将其存储起来供在计算上运行的服务器进程使用。
+ 为计算设置 WebSocket URL 环境变量，并与 Amazon GameLift Servers 服务建立 WebSocket 连接。
+ 从 Amazon GameLift Servers 服务请求最新版本的实例集的运行时配置。
+ 根据运行时配置说明启动和停止服务器进程。
Amazon GameLift Servers 代理的源代码和生成包说明可在 [Amazon GameLift Servers 代理](https://github.com/aws/amazon-gamelift-agent) GitHub 上找到。
## 关于该代理
Amazon GameLift Servers 代理专为您的实例集处理以下任务：
**进程管理**
+ 启动运行时指令中定义的新服务器进程。该代理可能使用与其一起部署的自定义运行时配置。或者，您也可以提供 `RuntimeConfiguration` 作为实例集定义的一部分。此方法的优势在于，您可以随时修改实例集的运行时配置。该代理会定期从 Amazon GameLift Servers 服务请求更新的运行时配置。
+ 监控服务器进程的激活情况，并在进程未及时激活时将其终止。
+ 向 Amazon GameLift Servers 发送心跳。如果该代理未发送心跳，计算可能会被标记为过时。
+ 在服务器进程终止时，向 Amazon GameLift Servers 报告。Amazon GameLift Servers 会使用此信息监控游戏服务器可用性，以便进行游戏会话放置。
+ 为服务器进程发出实例集事件，包括：
+ `SERVER_PROCESS_INVALID_PATH`：游戏服务器进程启动参数配置不正确。
+ `SERVER_PROCESS_TERMINATED_UNHEALTHY`：游戏服务器进程在激活后 3 分钟内未报告有效的运行状况检查，因此被终止。
+ `SERVER_PROCESS_FORCE_TERMINATED`：游戏服务器进程在发送 `OnProcessTerminate()` 后 30 秒内未完全退出。
+ `SERVER_PROCESS_CRASHED`：游戏服务器进程因某种原因而崩溃。
**计算管理**
+ 接收 Amazon GameLift Servers 服务发出的消息以关闭计算。
+ 提示由 Amazon GameLift Servers 终止计算。
**日志记录**
+ 将日志上传到 AWS 账户中的 Amazon S3 存储桶。
# 使用别名抽象化 Amazon GameLift Servers 实例集名称
Amazon GameLift Servers *别名*用于抽象化托管目标。托管目标告知 Amazon GameLift Servers 为玩家托管新游戏会话时可从中查找可用资源的位置。别名在以下情况下很有用：
+ 如果您的游戏不使用多舰队队列来放置游戏会话，则它会通过指定Amazon GameLift Servers舰队 ID 来请求新的游戏会话。在一个游戏的生命周期内，您会多次更换实例集，以更新服务器生成包、更新托管硬件和操作系统或者解决性能问题。使用别名来抽象化实例集 ID，以便将玩家流量从现有实例集无缝切换到新实例集。
+ 除了在游戏客户端请求创建新游戏会话时创建该会话之外，您还想执行其他操作。例如，你可能想将使用 out-of-date客户端的玩家引导到升级网站。
别名必须指定路由策略。该策略有两种类型。*简单*路由策略会将玩家流量路由到指定的实例集 ID，您可以更新该 ID 以重定向流量。*终端*路由策略会将消息传回客户端，而不是创建新游戏会话。您可以随时更改别名的路由策略。
如果您使用队列进行游戏会话放置，那么您在替换实例集时不需要别名来重定向流量。有了队列，您只需添加新实例集并删除旧实例集即可。此操作对玩家不可见，因为系统会自动使用新实例集来执行新游戏会话请求。它不会影响现有游戏会话。您可以使用实例集 ID 或别名来识别队列目标。
**Topics**
+ [创建 Amazon GameLift Servers别名](aliases-creating.md)
# 创建 Amazon GameLift Servers别名
本主题介绍如何创建用于游戏会话放置的 Amazon GameLift Servers 别名。
**创建别名**
使用 Amazon GameLift Servers 控制台或 AWS Command Line Interface（AWS CLI）创建别名。
------
#### [ Console ]
在 [Amazon GameLift Servers 控制台](https://console.aws.amazon.com/gamelift/)中，使用导航窗格打开**别名**页面。
1. 选择**创建别名**。
1. 输入别名**名称**。我们建议在别名名称中包含有意义的特征，以便在查看别名列表时提供帮助。
1. 根据需要输入别名**描述**。
1. 为别名选择**路由策略**。
1. 如果您选择了**简单**路由策略，请从列表中选择要与此别名关联的实例集 ID。该列表包含当前选择的 AWS 区域中的所有实例集。您必须在实例集所在的区域中创建别名。
1. 如果您选择了**终端**路由策略，请输入一个您希望 Amazon GameLift Servers 在响应游戏会话请求时返回给游戏客户端的字符串值。带有终端别名的请求会引发嵌入的消息的异常。
1. （可选）向别名资源添加**标签**。每个标签都包含定义的一个键和一个可选值。为您希望以有用的方式（如按用途、所有者或环境）分类的 AWS 资源分配标签。为每个要添加的标签选择**添加新标签**。
1. 当您准备好部署新实例集时，请选择**创建**。
------
#### [ AWS CLI ]
使用 [https://docs.aws.amazon.com/cli/latest/reference/gamelift/create-alias.html](https://docs.aws.amazon.com/cli/latest/reference/gamelift/create-alias.html) 命令创建别名。Amazon GameLift Servers 会在当前的默认 AWS 区域中创建别名资源（您也可以添加 --region 标签来指定其他 AWS 区域）。
至少要包含别名名称和路由策略。对于简单路由策略，请指定与别名位于同一区域的实例集的 ID。对于终端路由策略，请提供消息字符串。
------