Fleets
Fleet 代表一组专用服务器(DS)托管资源,同时也是负责 DS 部署和生命周期管理的服务。游戏可以指定以下内容:
1. 添加 Fleet
1.1 打开创建页面
选择 “DS Hosting> Fleets”,点击 “Add Fleet” 按钮:

点击按钮后,将打开以下创建页面:

1.2 基本配置

填写以下字段:
Fleet Name:Fleet 的描述性名称,无需唯一,但提交后不能修改。
Description:Fleet 的描述,提交后可以修改。
如果此 Fleet 与另一个 Fleet 有相似的配置值,可以点击 “Clone Config from Other Fleet” 来简化操作:

1.3 构建配置
1.3.1 添加新 Fleet 时配置主 Build
选择已创建的Build:

1.3.2 Fleet 创建后修改主 Build
如有需要,您可以随时修改 Fleet 的主 Build。从 Build 列表中选择新的 Build:

选择更新模式:

Force Update:立即更新所有机器,无论它们是否正在承载战斗会话。
Soft Update:在机器空闲(不承载任何战斗会话)时更新。使用旧主 Build 部署的机器将被标记为 “WATING_UPDATE” 状态,新的战斗会话不能放置在处于 “WATING_UPDATE” 状态的机器上。
点击提交按钮提交修改,然后刷新页面,等待更新完成(可能需要刷新页面查看):

1.4 进程配置

填写以下字段:
Launch Path:构建包中专用服务器可执行文件的路径,不能是脚本文件路径(*.sh、*.ps1、*.bat 等)。
Launch Param:启动时可传递给专用服务器进程的参数字符串。(可选)
Process Restart Attempt Time:服务器进程运行指定时长后,将被限制承载新的战斗会话。一旦其承载的所有现有战斗会话结束,服务器进程将尝试重启。这有助于 DS 避免因长时间运行导致的某些数据异常(例如 UE4 中的时间膨胀问题)。设置值不得大于 168 小时(7 天)。如果设置为 0,则忽略此设置。
1.5 部署配置
部署配置指定在哪里以及如何部署游戏服务器。
1.5.1 整体概念
PGOS 使用数据中心(Data Center)和区域(Zone)两个级别来管理游戏服务器部署:
Data Center:是云提供商在某个城市的物理数据中心,可以提供部署游戏服务器的机器资源。
Zone:是由地理区域内的多个数据中心组成的集群,这些数据中心共享一个扩展策略,并在集群内按需调度。Zone 的概念是抽象的,以便游戏能够有效利用地理区域内不同数据中心的机器资源,从而实现成本控制和资源备份。即使设置了备份数据中心,如果未被使用,游戏也不会为其资源付费。
以下是大致的概念图:

1.5.2 添加 Zone
添加一个 Zone,以便为特定地理区域提供游戏服务器服务。

1.5.3 添加 Data Center
添加数据中心,以利用特定城市云提供商的机器资源。


Data Center:云提供商在特定城市的物理数据中心,可以提供部署游戏服务器的机器资源。
Priority:区域需要放置战斗会话时数据中心的优先级,即当需要将战斗会话放置到服务器进程时,将从优先级最高的数据中心中选择服务器进程。如果多个数据中心具有相同的优先级,则首先选择对玩家延迟最低的数据中心。
优先级设置还会影响哪个数据中心优先进行扩容:优先级最高的数据中心将首先进行扩容。当多个数据中心具有相同的最高优先级时,扩容操作将力求在这些数据中心之间均匀分布空闲的服务器进程。
- Machine Type:PGOS 提供两种类型的机器:
* 按使用量计费的虚拟机(VM)
* 按月计费的裸金属(BM)
- Machine Models:允许在数据中心部署的机器型号。游戏必须至少选择 1 个型号,最多可以选择 10 个型号,排名靠前的型号将优先购买和部署。
1.5.4 扩展策略设置
扩展策略指定如何控制游戏服务器进程的数量。

1.5.4.1 Data Center的服务器容量
对于虚拟机Data Center:
指定数据中心的最大服务器进程数:
Data Center对可启动的服务器进程数量有最大限制。由于实际的服务器进程数量是 “Server Processes per Machine” 设置的整数倍,因此最终实际的服务器进程数量可能会略超过此最大限制。
为什么实际值可能会略超过设置值,这里有一个例子:假设数据中心的最大服务器进程数为 1000,且该数据中心只有 1 个机器型号,设置为每台机器 6 个服务器进程,那么最终实际的最大服务器进程数为 1002(=6×167),略超过设置值(1000)。
对于裸金属Data Center:
指定要从裸金属池分配给此区域的裸金属数量:

裸金属机器将一直运行,除非您将它们从裸金属池归还给后端,它们不会被冷却。因此,在裸金属机器上运行的服务器进程数量是固定的,不参与自动扩展。
点击此处了解有关在门户上管理裸金属实例的更多信息。
1.5.4.2 Zone的扩展模式
PGOS 提供两种扩展模式:
Fixed Server Processes:启动固定数量的游戏服务器,适用于调试(Debug)或质量保证(QA)场景。
Auto Scaling With Buffer:自动扩容或缩容,同时维持一定数量或百分比的可用游戏服务器进程。
Fixed Server Processes 模式
在此模式下,区域将维持的服务器进程数量等于所有数据中心的最大服务器进程数之和。这意味着托管这些服务器进程的机器将产生持续成本,因此此模式更适合服务器进程数量较少的调试或 QA 场景。

Initial Server Processes:区域的初始化服务器进程数。它是区域创建后的预热服务器进程数,也是区域的最小服务器进程数。由于实际的服务器进程数量是 “Server Processes per Machine” 设置的整数倍,因此最终实际的服务器进程数量可能会略超过此设置值。在 Fixed Server Processes 模式下,Initial Server Processes 等于 Max Server Processes,且不能修改。
Max Server Processes:区域的最大服务器进程数,其值是所有数据中心中 “Max Server Processes” 的总和。由于实际的服务器进程数量是 “Server Processes per Machine” 设置的整数倍,因此最终实际的服务器进程数量可能会略超过此最大限制。
Auto Scaling With Buffer 模式
在此模式下,区域将根据当前的战斗会话数量自动调整服务器进程的数量。此外,为了便于更快地放置战斗会话,区域将维持一定数量或百分比的可用游戏服务器进程。

Initial Server Processes:区域的初始化服务器进程数。它是区域创建后的预热服务器进程数,也是区域的最小服务器进程数。由于实际的服务器进程数量是 “Server Processes per Machine” 设置的整数倍,因此最终实际的服务器进程数量可能会略超过此设置值。其值必须是大于 0 的整数。
Max Server Processes:区域的最大服务器进程数,其值是所有数据中心中 “Max Server Processes” 的总和。由于实际的服务器进程数量是 “Server Processes per Machine” 设置的整数倍,因此最终实际的服务器进程数量可能会略超过此最大限制。
Buffer Rules:在运行中的服务器进程总数超过服务器进程最大限制之前,区域会维持可用的服务器进程以支持快速的战斗会话放置。有两种方式可以指定如何维持可用的游戏服务器进程:
有些游戏在不同的激活战斗会话规模下,战斗会话放置请求的增长率可能不同。因此,除了支持 “Single Rule” 外,PGOS 还提供 “Segment Rule”,允许游戏根据当前激活的战斗会话(已放置的服务器)数量设置不同的缓冲区。

- Maintain Available Servers:维持固定数量的可用 / 空闲游戏服务器进程。

- Maintain Available Percent:根据当前服务器进程的总数维持一定百分比的可用服务器进程。

1.5.4.3 为 Dev/Test 大区节省成本
如果Zone承载的所有战斗会话都已终止,那么在指定时间(冷却时间)后,PGOS 后端将尝试将所有按使用量计费的机器缩容至 0。此设置的目的是节省托管成本,特别是对于那些用于 Debug/QA 的 Fleet。

如果Zone或Data Center处于冷却状态且收到战斗会话放置请求,PGOS 后端将自动恢复等于 Initial Server Processes 数量的服务器进程来满足放置请求,无需任何额外干预。
1.5.5 Server Processes per Machine
在选择了要在Data Center部署的机器型号后,我们还需要指定每个机器型号允许同时运行的最大服务器进程数。

1.5.6 Server Process Hosting Battle Session Mode
此配置指定 DS 进程如何托管战斗会话。

有两种模式可供选择:
Simple Mode:一个服务器进程只能托管 1 个Battle Session,并且在Battle Session结束时会重启该进程。
Parallel Mode:一个服务器进程可以同时托管多个Battle Session,当一个Battle Session结束时,其插槽可被新的Battle Session使用。使用此模式时,游戏开发者需要实现 DS 同时管理多个Battle Session的必要逻辑。并且强烈建议为 “进程配置 - Process Restart Attempt Time” 设置一个有效值,以防止因服务器进程长时间运行而导致的意外问题。
此配置只能在创建 Fleet 时指定,之后不能更改。
1.6 存储配置

PGOS 为机器配置的默认存储大小为 50GB。但是,游戏可以根据需要配置更合适的空间大小。例如,如果游戏需要对 DS 进行性能分析并希望在本地输出大量性能日志,50GB 的空间可能不够。在这种情况下,游戏可以选择 Custom Capacity 模式并设置更大的空间大小。
1.7 提交创建
填写完所有这些配置字段后,点击 “Submit” 按钮,新的 Fleet 就创建完成了。
2. Fleet 列表
选择 “DS Hosting> Fleets”,您将看到所有已创建的 Fleet 列表,该列表显示了这些 Fleet 的一些关键信息:

右侧的 “Operation” 列显示了可以对 Fleet 执行的操作。
2.1 Fleet 状态
Fleet 可能处于以下状态之一:
2.1.1 状态:New
Fleet 正在新建中,尚未有任何资源。
2.1.2 状态:Launching
Fleet 正在获取资源。可能正在购买机器、在机器上下载 / 安装服务器 Build 或启动服务器实例。
2.1.3 状态:Available
Fleet 的游戏服务器实例(可能不是所有实例)工作正常,可以接受战斗会话放置。
2.1.4 状态:Available (Cooldown)
如果所有Battle Session都已终止且在一段时间内没有新的Battle Session放置,后端将尝试将所有机器缩容至 0,然后 Fleet 状态将变为 Available (Cooldown)。此机制的目的是节省成本,特别是对于那些用于 Debug/QA 的 Fleet。
处于 Available (Cooldown) 状态的 Fleet 仍然可以接受Battle Session放置,当突然收到Battle Session放置请求时,后端将自动恢复扩展策略指定的初始服务器进程以满足请求,然后 Fleet 状态将变为 Available。
2.1.5 状态:Unavailable
Fleet 出现无法自动修复的异常,无法提供Battle Session放置服务。此时,您可以查看 Fleet 的Events了解详情。
2.1.6 状态:Deleting
Fleet 正在被删除,通常是由手动删除操作触发的。
2.2 编辑 Fleet
点击 “Edit” 将进入 Fleet 编辑页面。关于 Fleet 的字段编辑,请参考添加 Fleet。

2.3 删除 Fleet
点击 “Delete” 会弹出确认窗口,询问是否确实要删除该 Fleet。


❗ 注意:
当 Fleet 与某些 Placer 相关联时,“Delete” 操作可能无法成功。
请确认 “Delete” 操作,因为它无法恢复。
2.4 查看详情
点击蓝色字体的 “Name” 将打开 Fleet 详情页面:

该页面显示多个子标签:
Summary:Fleet 的基本详情。
Configuration:查看或编辑 Fleet 配置。
Machine Instances:属于该 Fleet 的所有机器实例列表,您可以在此查看关键机器信息(如状态、IP、崩溃核心转储等)。
Battle Sessions:已放置在该 Fleet 上的战斗会话列表。
Events:该 Fleet 上发生的关键事件列表。
Crashes:该 Fleet 上发生的 DS 崩溃列表。
2.4.1 Summary
显示当前 Fleet 的基本信息。

关键字段含义:
Occupied / Total machines:占用的机器是指至少有一个战斗会话在该机器上运行。
Placed / Total DSs:已放置的 DS 是指战斗会话已被放置到该 DS 实例,它不再是空闲的 DS 实例。
Active Battle Sessions:当前正在进行的战斗会话数量。
Active Player Battle Sessions:当前在战斗会话中进行游戏的玩家数量。
2.4.2 Configuration
您可以在此查看当前 Fleet 配置,如果要编辑,请参考添加 Fleet。
2.4.3 Machine Instances
属于该 Fleet 的所有机器实例列表:

您可以按 ID、IP、状态(Status)、Build、IDC 筛选机器实例列表。
机器列表的关键列描述:
- Last core dump Time: 如果机器上发生过 DS 崩溃,此处将显示最后一次崩溃的时间。
❗ 注意:
如果 DS 程序没有生成崩溃转储的功能,此列将没有数据。
对于 Unreal DS 程序,只需在启动参数中添加 “-core” 即可使程序生成崩溃转储。
点击时间值可打开该机器的 DS 崩溃列表:

点击 “Details” 查看核心转储的详情,包括核心转储堆栈:

您也可以点击 “Download” 将核心转储文件下载到本地进行进一步分析。
- Operation Monitoring

点击 “Operation” 列中的 “Monitoring” 打开监控页面,查看机器的 CPU / 内存使用趋势:

您可以选择特定的日期范围和时间粒度,查看收集样本的平均值、最大值和最小值,还可以点击显示 / 隐藏某条曲线。

Operation Terminal
点击 “Operation” 列中的 “Terminal” 启动机器上的代理终端:

终端服务成功启动后,您可以点击 “Connect Terminal” 跳转到终端。
❗ 注意:
由于合规问题,我们只能为您提供 P2P 直接连接和自签名证书。但是,我们会提供证书的 sha256 值。请根据页面上的提示验证证书的 sha256 值是否正确。

连接成功后,您可以通过终端操作机器。Windows 机器支持 VNC 和 Shell,Linux 机器支持 Shell。每次操作都需要创建一个新的终端会话。

创建会话后,您将能够通过终端操作机器:

在右侧,支持文件操作,您可以向机器上传文件、从机器下载文件,并进行图形化文件管理。

- Operation Explore

点击 “Operation” 列中的 “Explore” 打开并浏览该机器上的游戏 DS 文件夹:

您可以查看游戏目录中的任何文件 / 文件夹,或下载它们,甚至可以在线预览一些文本文件:

- Operation Reboot

点击 “Operation” 列中的 “Reboot” 重启机器实例,会弹出确认窗口询问是否确实要重启。

- Operation Revoke

点击 “Operation” 列中的 “Revoke” 回收机器实例,会弹出确认窗口询问是否确实要回收。

❗ 注意:
“Revoke” 操作是一个强制操作,会立即终止机器实例,无论是否有活跃的战斗会话在运行。由于这可能导致玩家与 DS 断开连接,请谨慎执行此操作。
2.4.4 Battle Sessions
已放置在该 Fleet 上的战斗会话列表,您可以按 ID、Source Configuration、机器 ID、IDC 和 Build 筛选列表。

点击 “ID” 查看战斗会话的详情:

点击 “Monitoring” 链接,您可以查看战斗会话期间机器的性能:

2.4.5 Events
该 Fleet 上发生的关键事件列表:

您可以按 IDC、事件级别(Event Level:Info/Warning/Error)、事件产生者(Event Producer:Fleet/machine)筛选事件列表,或使用事件消息中的关键字进行筛选:

2.4.6 Crashes
该 Fleet 上发生的 DS 崩溃列表,您可以按 IDC 或 Build 筛选列表。

点击 “Stack ID” 或 “Details” 链接,您可以查看崩溃详情:

如果需要,您可以点击 “Download” 按钮下载核心转储文件。