如何将本地部署的Tiger数据分析平台迁移至AWS

能否直接关停本地集群通过SCP传镜像完成迁移 #

答案是否定的，不可直接执行该操作，核心原因如下：

• 仅传输Docker镜像只覆盖了Tiger平台的运行程序文件，你的ETL流程配置、LDM模型定义、指标规则、看板配置、元数据、任务运行日志等核心业务数据全部存储在本地集群的持久化存储卷中，未同步这些数据的前提下迁移过去的平台是空实例，无法继承原有配置能力
• 直接关停本地集群前未做运行态任务校验，会导致正在执行的ETL任务、指标计算任务中断，可能产生脏数据，甚至导致持久化数据损坏
• 数据源仍留在本地，AWS侧部署的Tiger平台的网络连通性、数据源访问权限、专线带宽稳定性均未做验证，直接关停会导致数据分析业务完全中断，无回滚能力

理论层面迁移步骤 #

一、前置准备阶段 #

• 梳理本地Tiger平台的全量资源清单：包括Docker镜像的版本/Tag、K8s部署的YAML配置清单、持久化存储卷的容量/使用量、所有数据源的连接配置（地址、账号、权限白名单）、已配置的任务调度规则
• 提前在AWS侧完成资源预搭建：
  • 若采用EC2部署则申请匹配配置的EC2实例，安全组放开本地数据源访问端口、Tiger平台的服务端口，同时将EC2的内网地址加入本地数据源的访问白名单
  • 若采用EKS部署则完成EKS集群创建，配置对应节点组、CSI存储类（匹配本地持久化卷的性能要求）、VPC网络配置确保和本地IDC专线互通
• 做一次全量的Tiger平台业务快照：暂停所有非核心定时任务，待所有运行中任务执行完成后，对持久化卷做一致性快照，同时导出平台全量配置备份文件备用

二、镜像与资源配置迁移 #

• 将本地Tiger平台的所有Docker镜像导出为tar包：执行docker save <镜像名:Tag> -o <导出包名>.tar，K8s部署的可通过kubectl get pods -o jsonpath='{.items[*].spec.containers[*].image}'获取全量镜像列表后批量导出
• 通过专线/SCP将镜像tar包传输到AWS侧，EC2部署直接执行docker load -i <镜像包名>.tar加载镜像；EKS部署可将镜像推送到AWS ECR私有镜像仓库，调整部署YAML中的镜像拉取地址为ECR地址
• 同步本地的部署配置到AWS侧：Docker AIO部署的同步原启动命令、端口映射、持久化卷挂载配置；K8s部署的同步Deployment、StatefulSet、Service、Ingress、ConfigMap、Secret等全量资源配置，注意将配置中的本地相关地址（比如原本地的存储地址、服务发现地址）替换为AWS侧的对应地址

三、持久化数据迁移 #

• 将本地持久化卷的全量数据通过专线传输到AWS侧：
  • Docker AIO部署可直接打包本地挂载的持久化目录，传输到EC2对应挂载目录解压即可
  • EKS部署可通过rsync、Kubernetes卷快照迁移工具等将本地持久化卷数据同步到EKS的PV中
• 数据同步完成后做一致性校验：对比本地和AWS侧的元数据条目数、配置文件MD5值、核心看板的指标计算结果，确保数据没有丢失或损坏

四、功能与连通性验证 #

• 启动AWS侧的Tiger平台，先做连通性测试：验证所有本地数据源的连接是否正常，测试小批量ETL任务的执行速度、结果是否和本地执行结果一致
• 全量验证业务功能：检查所有LDM模型、Metrics定义、Insights报告、KPI看板是否正常加载，验证所有定时任务的调度规则是否正常生效
• 性能压测：模拟业务峰值请求，验证专线带宽是否满足AWS侧平台拉取本地数据源的带宽要求，确保没有延迟过高、任务超时的问题

五、流量切割与下线本地集群 #

• 先将小比例的分析请求切到AWS侧的Tiger平台，观察24~72小时无异常后逐步提升流量比例，期间保留本地集群处于运行状态，出现问题可随时切回本地
• 待流量100%切到AWS侧且稳定运行至少7天后，先暂停本地集群的所有任务，确认业务无影响后再关停本地的Docker实例或Kubernetes集群
• 最后做好迁移后的配置备份，完成迁移流程

内容的提问来源于stack exchange，提问作者Daniel Gray