跳到内容
SIAX.io

迁移指南 · 来自 Microsoft Azure

从 Microsoft Azure 迁移到 SIAX

多数离开 Azure 的人并没有离开整个 Azure。他们迁移的是那些付出最多、平台价值最少的工作负载:仅仅在跑一个容器的虚拟机、本来用容器也行的 App Service 应用、就是普通 Postgres 的数据库,以及就是普通对象存储的 blob 存储。留下来的通常是身份识别,以及任何贴近 Microsoft 365 的东西。

这是合理的立场,我们也无意提出别的做法。对正确的东西做部分迁移,能在不动摇你现有身份与权限结构的情况下明显降低成本。在我们这里,一个 App Service 应用变成 App Hosting 上的容器,一台虚拟机变成 VPS 或专用服务器,Azure Database for PostgreSQL 变成 Managed Postgres,Blob Storage 变成带 S3 API 的对象存储。

彼此要对得不到什么讲清楚。我们没有 Entra ID、Functions、Logic Apps、Private Link 或 ExpressRoute 的托管对应物,也缺少 Azure 所拥有的认证。一个不这么假设的项目会在第三周掉进沟里。

所需时间

按工作负载来算,而不是按小时。单个 App Service 应用需要一天。带有几台虚拟机、一个数据库和 blob 存储的典型配置需要三到六周的日历时间,其中大部分花在数据传输和验证上。

停机时间

因工作负载而异。无状态应用通过并行运行实现无中断迁移。数据库需要一个从几分钟到一小时的写入窗口。带本地状态的虚拟机需要计划内的停机,通常是一到四小时。

01

操作步骤

  1. 1

    按工作负载盘点,并分成三堆

    按资源组导出资源清单,并包含每个资源最近三个月的实际成本。然后把每个工作负载归入迁移、保留或退役。很多团队在这一步会发现自己已经没人用的资源,无论你对其余部分做什么决定,这些都应该关掉。

  2. 2

    决定什么留在 Azure

    Entra ID 通常留下,尤其是在你运行 Microsoft 365 的情况下。与 Azure 深度集成的 Functions 和 Logic Apps 同样如此,因为重写的成本大于节省。把决定和理由写下来,这样每次有人纳闷为什么 Microsoft 的账单没有归零时,你都不必重新争论一遍。

  3. 3

    把每个工作负载匹配到正确的目标

    App Service 和 Container Apps 变成从 99 克朗起的 App Hosting。虚拟机变成从 59 克朗起的 VPS,或者当你需要有保障的核心时,从 890 克朗起的专用服务器。Azure Database for PostgreSQL 变成从 89 克朗起的 Managed Postgres。Blob Storage 变成每 100 GB 25 克朗的对象存储,Azure Backup 变成我们每 100 GB 19 克朗的备份。按照实际使用规模来,而不是按三年前某人选的虚拟机大小。

  4. 4

    迁移数据库

    在开始之前检查 Flexible Server 的版本级别和扩展。对较小的数据库取一份 pg_dump 并针对 Managed Postgres 运行 pg_restore,对较大的则设置逻辑复制。在重定向应用之前,对照源核实行数和关键聚合值,并在这之后让 Azure 实例保持一段时间的可读。

  5. 5

    迁移 blob 数据并核算出网流量

    用 rclone 或 azcopy 把数据复制到我们兼容 S3 的 endpoint,并校验校验和。先测量数据量:Azure 的出站流量按 GB 计费,几个 TB 会变成一张实实在在的账单。分批运行传输,最后做一次最终同步,让最后的窗口保持很短。

  6. 6

    重建网络与认证

    VNet、NSG、Private Link 和 ExpressRoute 在我们这里没有对应物。环境之间的私有流量用 WireGuard 或 Tailscale 加上防火墙规则解决。使用 managed identity 和 DefaultAzureCredential 的代码必须切换到密钥管理器中的真实密钥,并配上一套由你自己负责的轮换流程。这通常是整个迁移中最大的编码工作量。

  7. 7

    按工作负载切换并妥善停用

    一次迁移一个工作负载,让它并行运行直到指标稳定。在每次 DNS 切换前降低 TTL。一切验证无误后,拆掉 Azure 资源,但先检查你的 Reserved Instances 和 Savings Plans,因为即使资源已不存在,承诺仍然会被持续计费。

02

真正棘手的地方

  • Entra ID 在我们这里没有对应物。要么你继续把它作为身份提供者(这没问题),要么你在自己的服务器上运行 Keycloak 或 Zitadel,并接手运营登录。后者是一个独立的项目,不是本项目的其中一步。
  • Azure Functions 和 Logic Apps 必须重写。Triggers 和 bindings 不存在,因此队列处理、定时器和 HTTP 端点变成长期运行服务中的显式代码。结果往往更简单,但那是重写,而不是迁移。
  • Managed identity 会消失。任何依赖 Azure 自动发放短期 tokens 的代码,都需要真实的凭据和一套轮换流程。
  • 当你要迁出去时,Azure 的出站数据流量是要花钱的。在承诺预算之前先测量体积,尤其是 blob 存储和数据库 dump。
  • Azure 有 ISO 27001 和 SOC 2。我们没有。如果你的客户合同或采购流程要求供应商必须有认证,那是一个障碍,而且应该现在就发现,而不是在合同审查时才发现。
03

成本示例

两台应用服务器、一个 Postgres、500 GB 对象存储和 100 GB 备份:两台 VPS 各 59 克朗,Managed Postgres 从 89 克朗起,对象存储 125 克朗,备份 19 克朗,因此在最小的规模下每月大约 351 克朗,不含增值税。在 Azure 那边,两台 B 系列虚拟机、一个 Flexible Server 和 blob 存储,按月费表大约在 2,500 到 3,500 克朗之间,还不含出网流量,而且 Microsoft 的价格不断变化,并因地区和承诺而异。

04

常见问题

我们必须完全离开 Azure 吗?
不必,多数人也不会。最常见的结果是计算、数据库和存储迁移,而 Entra ID 以及任何贴近 Microsoft 365 的东西保留不动。你用 WireGuard 或 Tailscale 把两套环境连接起来。
我们能继续用 Entra ID 登录吗?
可以。你在我们这里的应用可以像以前一样通过 OIDC 把 Entra ID 用作身份提供者。我们不提供托管身份服务,所以另一种选择是你自己运行一套,对大多数人来说这不值得切换。
我们的 Reserved Instances 怎么办?
无论资源是否还在,它们都会持续计费到期限结束。尽早核对承诺,并把切换日期与它们对齐,否则你会比自己原意更久地为两套平台买单。
你们没有 Azure 那套认证。你们怎么处理?
我们直说:我们既没有 ISO 27001、SOC 2,也没有 PCI-DSS。我们能提供的是带数据处理协议的 GDPR 合规、所有数据都在欧盟境内、以及一个完全基于开源、且可以真正接受审计的完整技术栈。这对很多人够了,但并非对所有人都够,你应该带着这个认知做选择。