cloud-sre

迁移 AWS S3 File Gateway 时，如何不破坏用户盘符映射

一个替换旧 S3 File Gateway、重建缓存并用 SSM State Manager 迁移 Windows 用户盘符的实践模式。

Jun 12, 2026
AWSStorage GatewayWorkSpacesSSMmigration

替换 AWS S3 File Gateway 看起来很简单，直到这个 gateway 同时承载一批 Windows 桌面的关键 SMB 盘符。存储后端也许是 S3，但用户依赖的是稳定的盘符、基于目录的认证、本地缓存行为，以及可预测的切换过程。

这篇文章描述一种迁移模式：保持 S3 数据不动，干净地替换 gateway appliance，并用 AWS Systems Manager 自动完成 Windows 盘符重映射。

迁移目标

这个环境有四个要求：

  • 在旧 gateway 支持期限前完成替换
  • 保留现有 S3 object 和 SMB share 名称
  • 保持用户看到的盘符不变
  • 避免逐台手工配置 Windows 桌面

最终架构是：

Windows desktops
      |
      | SMB with directory-based authentication
      v
New S3 File Gateway
      |
      | Private VPC endpoints
      v
Existing S3 bucket

gateway instance 和 cache 被替换，S3 bucket 仍然是事实来源。

先保护回滚路径

修改旧 gateway 之前，先收集足够证据，确保后续可以恢复或解释当前状态：

  • 导出 gateway、SMB 和 file-share 配置
  • 对挂载的 volume 禁用 delete-on-termination
  • 为 system volume 和 cache volume 创建 snapshot
  • 等待所有 snapshot 完成
  • 确认 CachePercentDirty 已经归零

dirty cache 检查比简单的 running 状态更重要。cache 干净意味着没有还没同步到 S3 的本地写入。

为什么放弃复用旧磁盘

早期尝试过把旧 system disk 和 cache disk 挂到新的 EC2 instance 上。网络路径看起来是健康的：预期 TCP 端口可以建立连接。但 appliance 本身并不健康：

  • activation endpoint 返回空 HTTP 响应
  • 浏览器显示 ERR_EMPTY_RESPONSE
  • SSH 暴露了 server banner，但在 key exchange 阶段卡住

这里有一个重要的诊断边界：

Open TCP port != healthy appliance service

继续调试旧 boot disk 会扩大中断窗口，却不会改善数据恢复位置。因为持久化文件已经在 S3，dirty cache 也为零，干净部署一个新 gateway 是风险更低的路径。

用同一份 S3 数据构建干净 gateway

成功方案使用当前版本的 Storage Gateway image 和新的本地磁盘：

  1. 部署新的 S3 File Gateway。
  2. 通过所需的公网或 VPC-hosted service endpoint 连接。
  3. 分配新的 cache storage。
  4. 加入现有 directory service。
  5. 创建一个由现有 S3 location 支撑的 SMB share。
  6. 重新应用 logging、alarm、IAM、security group 和 instance protection。

为了保留 S3 object，不需要复制本地 cache。新 gateway 会在文件被访问时重新构建 cache。

用 SSM 自动迁移 Windows 盘符

AWS Systems Manager command 以 SYSTEM 身份运行，而网络盘符属于用户 session。一个只用 SYSTEM 执行 net use 的命令可能执行成功，但登录用户看不到这个盘符。

可靠模式是：

  1. 用 SSM State Manager 在每个受管 Windows 节点上安装 PowerShell 脚本。
  2. 把脚本注册到 HKLM Run entry。
  3. 用户登录时执行真正的映射动作。
  4. 日志写到用户的 %LOCALAPPDATA%，不要写到受保护的系统目录。

登录脚本要保守：

  • 如果盘符未使用，就映射到新 share。
  • 如果盘符指向旧 share，就替换它。
  • 如果盘符是本地磁盘或无关网络 share，就不做任何事。

这样可以避免迁移脚本覆盖用户无关的配置。

把离线桌面当成正常状态

State Manager association 执行时，很多桌面节点可能是停止状态。SSM 会把这些 target 报告为 Undeliverable，这对离线 instance 来说是预期行为。

使用 scheduled association，让桌面启动后自动重试配置。面向用户的沟通应该包含：

  • 基于 association interval 的现实传播窗口
  • 预期的 drive label 和 path
  • sign-out / sign-in 兜底步骤
  • 如果映射仍失败，请用户提供执行时间、截图和本地日志

这样才能把一次基础设施发布变成可支持的用户侧变更。

验证完整路径

不要在 gateway 显示 RUNNING 后就停止。要从普通用户桌面验证：

echo gateway-test > E:\gateway-test.txt
type E:\gateway-test.txt
del E:\gateway-test.txt

还要验证：

  • File Explorer 中出现预期盘符
  • 现有目录可见
  • 创建、读取、更新、删除操作可用
  • SMB session 指向新 gateway
  • gateway 和 file-share log 正在接收事件
  • availability 和 dirty-cache alarm 都是健康状态

按依赖顺序退役旧栈

新路径验证后，按受控顺序删除旧资源：

  1. 删除旧 SMB file share，不强制删除。
  2. 删除旧 gateway。
  3. 终止旧 EC2 instance。
  4. 清点未挂载的 EBS volume。
  5. 只删除已确认不再使用且已有所需 snapshot 的 volume。

要明确排除新 gateway 正在使用的 system volume 和 cache volume，避免被清理脚本误删。

可复用经验

  • S3 是持久数据层；当 dirty write 为零时，gateway cache 是可替换的。
  • 网络可达不等于应用健康。
  • 干净替换 appliance 可能比救活旧 boot disk 更安全。
  • 用户可见的盘符必须在用户 session 中创建。
  • SSM scheduled association 比一次性命令更适合处理间歇在线的桌面。
  • 监控、用户沟通和清理顺序都是迁移设计的一部分，不是迁移后的杂项。