摘要
- IBM Cloud 拥有可验证的运营足迹。其当前的位置注册列出了九个都市多区域、四个单园区多区域和 42 个经典基础设施数据中心，而其文档将逻辑 VPC 区域映射到物理设施和网络接入点。
- 区域选择并不会使容量变得抽象。IBM 表示某些依赖硬件的配置文件并非在所有区域都可用，按数据中心公开裸机库存，记录容量不足错误，并销售将容量专门分配给选定区域的预留服务。
- 韧性仍然是一项架构购买，而不是账户的自动属性。单个区域服务器在区域故障后不会移动到另一个区域，Direct Link 并非固有冗余，单园区区域可能共享依赖关系，区域灾难恢复在很大程度上仍是客户的责任。
- 数据局部性也是特定于服务的。IBM 表示，区域和区域性服务的客户内容会在选定区域中存储和处理，但账户元数据和全局控制功能可能在其他地方处理。因此，备份、支持访问、跨区域复制和退出程序都应成为局部性决策的一部分，而不是事后才考虑。
区域名称是对特定建筑中机器的声明
云地理通常被呈现为一个整洁的城市名称菜单。IBM Cloud 的公开文档使得这种抽象异常容易被解构。其位置注册将区域描述为一个独立的地理领土，包含一个或多个区域，通常以大都市区命名。目前列出了达拉斯、华盛顿、圣保罗、多伦多、法兰克福、伦敦、马德里、悉尼和东京的完整多区域区域。另外还列出了钦奈、蒙特利尔、孟买和大阪的单园区多区域区域。
两种区域类型的区别并非表面功夫。IBM 表示，完整多区域区域使用三个或更多数据中心，位于独立站点，具有独立的电力、冷却和网络连接，且区域之间的距离至少为一英里。而单园区多区域区域则将三个区域放置在单个建筑的不同部分或同一园区内的建筑中。其电力、冷却、网络和物理安全依赖可能重叠。IBM 表示两种形式具有相同的服务水平承诺，但也警告说，由于区域之间的联系更紧密，数据中心灾难可能影响整个单园区区域。
这为买家提供了有用的首要规则：区域标签标识的是市场和延迟区域，而不是物理独立性的统一量。法兰克福的三个区域在物理上不等同于蒙特利尔一个园区内的三个区域。即使在完整区域类别中，IBM 也只是公布了最小间隔，而没有公布每一对站点的距离、洪泛平原、公用设施、导管或运营商细节。买家可以知道这些区域旨在作为独立的故障域，但并不知道这些域仍然可能相关的所有机制。
IBM 的注册进一步通过公开逻辑名称与物理名称之间的转换来实现。VPC 客户看到的区域如us-south-1，但账户会收到一个映射到通用物理指定，如us-south-dal10-a。IBM 表示，该映射是在区域中创建第一个 VPC 资源时建立的，并由 IBM 决定。达拉斯目前有四个与 DAL10、DAL12、DAL13 和 DAL14 相关的通用位置，尽管面向普通账户的区域呈现三个编号区域。客户可以在创建后检查分配情况，在极少数情况下可以请求技术客户经理进行更改，但 IBM 会个别评估此类请求。
当组织混合使用 VPC、Power Virtual Server 和经典基础设施时，这一点很重要。VPC 使用账户的逻辑到物理映射；经典和 Power 资源可以根据特定的数据中心代码进行订购。IBM 明确建议先创建 VPC 资源，检查通用区域，然后在打算共置时将其他资源放在相同的物理设施中。仅凭城市名称对于该任务来说过于宽泛。
当前的经典注册列出了 42 个数据中心：美洲 19 个，欧洲 12 个，亚太地区 11 个。其中包括六个达拉斯站点、四个华盛顿站点、四个伦敦站点，以及其他几个市场各有三个站点。这是一个运营中的全球托管资产的强有力证据，而不是一张推测性地图。它还表明，为什么“IBM Cloud 区域”的单一数字会误导人。VPC 区域、单园区区域、经典建筑、Power 位置和网络接入点是相关的，但并非可互换的单位。
IBM 表示，一个经典数据中心可以包含多个 Pod，每个 Pod 由机架、服务器、网络、存储和备用发电机组成。将服务器跨 Pod 放置可以提高可用性，但该公司提醒说，数据中心本身并不提供与同一位置的多区域安排隔离的功能。Pod 是建筑内更小的故障和容量域；区域是客户用来分离 VPC 资源的单位；区域将区域分组；而全局控制功能仍然可以位于所有这些层之上。只有在将这些层分开之后，物理购买才开始。
SoftLayer 留给 IBM 的是一个托管资产，而非无限弹性池
这种物理侧重部分源于历史。IBM 于 2013 年收购了 SoftLayer，并将其与 IBM SmartCloud 合并。IBM 该季度的备案文件记录现金对价为 19.77 亿美元。一份 IBM收购简报将 SoftLayer 描述为一家总部位于达拉斯的基础设施提供商，为 21,000 个客户提供专用服务器、虚拟服务器和私有云服务。其吸引力不仅在于软件，还在于一个已安装的托管系统，包括客户、设施、自动化和网络。
这种传承体现在经典基础设施与 VPC 的共存中。经典客户仍然可以选择命名的数据中心，并根据物理库存订购虚拟或裸机服务器。VPC 提供更标准化的区域性资源和软件定义网络。现在，IBM 推荐将 VPC 用于许多现代部署，然而经典资产及其运营假设对现有客户、VMware 部署、托管公司以及围绕 SoftLayer 时代网络构建的应用程序仍然重要。
这一资产的经济学体现在 IBM 自身的可用性规则中。服务推出政策将产品分为核心服务和市场驱动服务。核心服务（包括 VPC、Object Storage、Kubernetes、OpenShift、PostgreSQL 和密钥管理）预计在每个多区域区域中提供。其他服务则根据客户需求进行部署。IBM 表示，新的核心服务应在首次区域部署后 90 天内覆盖所有多区域区域，更新应在 30 天内跟进，但它明确指出，依赖于硬件的配置文件和功能并非在所有区域都可用。
这就是地图背后的商业逻辑。开放一个城市并不意味着以无限深度安装每一个处理器、加速器、存储层和设备。提供商必须决定为多少机架通电，库存哪些服务器代次，保留多少网络和存储余量，以及专业服务的需求是否会回报本地部署和支持。一项服务可以存在于一个区域中，而特定的配置文件仍然缺失或稀缺。
达拉斯提供了一个需求决定容量的具体例子。IBM 宣布将 DAL14 作为额外的 VPC 区域，称其为该公司在达拉斯的第十个数据中心，也是该地区的第四个可用性区域设施。该公告表示，此次扩展增加了 VPC 工作负载的容量，并补充了两个网络接入点和市场上的其他基础设施。关键词是容量。一个新区域是一项涉及建筑、电力输送、冷却、光纤、服务器和运营覆盖的资本和供应决策，而不是在控制台中添加的新标签。
IBM 全公司的环境数据提供了对物理账单的广泛了解，尽管不能将其误认为是仅限 IBM Cloud 的测量。IBM 报告称，其数据中心在 2025 年的加权平均电力使用效率为 1.39，其中 85% 的电力来自可再生能源，44 个数据中心使用 100% 可再生电力供应。同一份能源披露指出，一些可再生电力来自房东以及直接电力供应商。它并未公布每个设施的云消耗量、合同兆瓦、电网约束或备用燃料持续时间。这些汇总数据确立了实质性的运营努力；但它无法告诉达拉斯客户，在特定区域之下是何种公用设施或房东依赖。
因此，区域选择带有两种代价。可见的代价是计算、存储和流量的费率。不太可见的代价是提供商决定在该位置安装足够合适的容量，以及客户决定预留或复制这些容量。低延迟的本地部署、专用硬件和充足的备用库存都在争夺相同的机架和电力。地图显示了 IBM 可以在哪里销售；订单屏幕揭示了它现在可以提供什么。
安装的容量只有在请求的配置文件可用时才变得可用
IBM 的裸机文档对库存情况直言不讳。其服务器指南指出，客户可以查看每个数据中心中哪些快速配置服务器可用。如果所选服务器不可用，订购界面会标识出存在该配置的其他位置。快速配置系统通常在 30 到 40 分钟内可配置，而更广泛的裸机配置可能需要长达四小时。可选的扩展硬件测试可能会增加两小时，IBM 表示，关键测试错误会导致在交付前更换组件。
这是最字面意义上的安装容量。一个机箱必须存在，配备正确的处理器、内存和驱动器，连接到可用的网络端口，通过压力测试，并保持未分配状态。一个数据中心可能处于运营状态，但所需的机器却不可用。搬到另一个建筑可能解决库存问题，但会改变延迟、故障隔离、驻留性或交叉连接设计。
经典虚拟服务器在池化级别暴露了相同的限制。IBM 的容量故障排除页面记录了当路由器或数据中心缺乏资源来满足请求时的“容量不足”错误。建议的响应包括等待、选择另一个路由器或建筑、订购更少或更小的实例、将请求分散到多个数据中心，或更改存储类型。该页面还将经典 GPU 供应限制在指定的设施子集中。弹性是真实的，但受到可用主机、网络连接、存储以及与物理站点绑定的产品目录的限制。
通过预留，VPC 容量可以变得更具可预测性。IBM 提供针对选定区域中数量和配置文件的一年或三年承诺。它为虚拟服务器提供高达 60% 的折扣，为裸机提供高达 55% 的折扣，同时在期限内专用预留容量。裸机预留甚至在服务器配置之前就保留了容量。预留创建可能仍需要时间，并且在容量专用之前可能会失败。
这种安排清楚地揭示了权衡。按需购买为客户提供了灵活性，但即时可用性受共享池的限制。预留通过支付对特定配置文件和区域的承诺性声明来减少这种不确定性。它不会预留服务器周围的所有依赖项。网络带宽、存储、软件、镜像、配额、负载均衡器和恢复容量都有各自的条件。一个预留区域也不会仅仅因为计算在那里得到保证就成为灾难恢复站点。
可用容量还取决于代次和生命周期。IBM 表示，一些成熟设施包含 1U 单插槽服务器，没有双路电源供应，并建议需要电源冗余的客户考虑 2U 机箱。其当前的韧性指南指出，数据中心具有多个电源供应、光纤链路、发电机和电池，同时仍然指出了这一服务器级别的例外。这是一个有用的警告，防止将建筑冗余视为每台机器自动继承的属性。
这种区别也延伸到软件可用性。所有多区域区域都提供一组核心服务，但市场驱动的服务可能会缺失，并且服务的本地数据平面可能依赖于 Object Storage、密钥管理、数据库、身份或网络功能。一个区域可能有充足的通算计算能力，但仍然缺乏应用程序所需的特定硬件或托管服务。在认定一个位置可行之前，运营商必须测试整个物料清单，包括故障转移日的备用容量，届时许多客户可能同时尝试进行配置。
IBM 运营着云层，而公用设施、房东和运营商仍然处于底层
IBM 的共享责任声明将设施、物理网络、存储、管理程序和物理服务器置于 IBM 对于公共基础设施服务的运营责任之下。客户仍需负责其数据、应用程序和操作系统，而虚拟服务器、存储和网络则属于共享责任。对于灾难恢复，IBM 提供底层服务，但客户必须在第二个区域中创建资源，并管理应用程序和数据的恢复。
这份责任声明比承诺租用机架空间更有力。它指出 IBM 对客户在公共服务之下的物理层负责。它并未确立 IBM 拥有每栋建筑、公用设施连接或城市光纤路由。公开位置列表中将钦奈和孟买区域与 Airtel 的名称联系在一起，而 IBM 的能源报告提到通过房东获取的可再生电力。IBM 还描述了需要外部连接提供商和客户资助的交叉连接的 Direct Link 安排。因此，即使 IBM 仍然是合同上的云运营商，该资产也有着多个运营商边界。
在设施层面，IBM 在其全球数据中心页面上宣传 N+1 电力和冷却以及 24 小时物理安全。其更深入的韧性文件指出，站点使用多个电源供应、专用发电机和电池。这些声明支持了工程备用系统的存在。但它们没有披露公用变电站、燃料合同、负载下的运行时间、发电机测试结果、水依赖、开关设备制造商，或者两个名义电源供应是否共享上游电网元素。
公开事件档案显示了为什么那些缺失的细节很重要。IBM 将重大事件的分析报告保留五年。其事件索引包括：影响 FRA05 的 2023 年 7 月公用电网中断、2022 年 10 月影响首尔 01 数据中心的火灾、2021 年 4 月的华盛顿停电、2020 年 12 月 SAO01 的冷却基础设施电力故障，以及与指定设施和 Pod 相关的网络中断。仅凭标题并不能确立当前的弱点或揭示所有补救措施。它们表明电网、火灾、冷却、建筑网络和 Pod 故障是该资产中的实际类别，而不是遥远假设。
因此，有韧性的购买必须在几个边界上进行测试。工作负载是占用一台机器、一个 Pod 中的多台机器、一个建筑中的多个 Pod，还是独立的区域？选定的区域是在不同的站点上还是在同一个园区？两个站点是否依赖于相同的地铁运营商走廊？数据的第二份副本是在另一个区域、另一个地区，还是仅在同一个房间中的冗余设备上？恢复区域是否有足够的兼容计算和托管服务容量？每个答案都会改变客户实际能够存活下来的程度。
公开披露的限制也应保持可见。IBM 并未提供站点逐一的所有权登记、公用设施图表、发电机运行时间表、机架库存或地铁光纤管道地图。其区域设计和事件历史是实质性的证据，但它们不允许外部人员验证物理多样性，直至每个租赁、馈线和管道。大型受监管客户可能能够在保密条件下获取依赖性报告；IBM 表示可以通过合规支持请求此类报告。公开买家不应默默假设普通产品页面中存在相同的细节。
主干网络十分广泛，但客户的私有入口仅作为一条路径开始
网络是 IBM Cloud 文档记录最完善的物理系统之一。一份物理基础设施指南描述了分离的公共和私有网络，数据中心内成对的客户交换机和路由器，以及在数据中心和网络接入点处的多个运营商连接。它指出，设施之间的流量使用多条 10 或 40 Gbps 的主干连接。面向 VMware 的各个裸机主机可以接收冗余的 10 或 25 Gbps 连接，分别接入不同的架顶交换机，同时用于公共和私有网络。
IBM 还表示，其数据中心之间的流量保留在其主干网和自治系统内，而不是跨越其他网络。私有连接描述将此主干网呈现为一个全球系统，连接区域内部、区域之间以及跨区域的资源。在公共边缘，IBM 的对等政策要求运营对等方维护路由记录和 24 小时网络联系。
存在独立的佐证，但有局限。PeeringDB 关于AS36351的公开记录将 SoftLayer Technologies（一家 IBM 公司，也称为 IBM Cloud）标识出来。2026 年 7 月，它报告了 1 至 5 Tbps 的流量、约 1,800 个 IPv4 前缀、450 个 IPv6 前缀以及在多个大洲的交换连接。PeeringDB 是由运营商维护的，而非审计的容量声明。它支持该网络的存在和广泛覆盖；它不能证明任何两个 IBM 设施之间的实际流量、私有的主干路由、拥塞余量或光纤多样性。
IBM 自身的主干声明雄心勃勃：其韧性页面表示，在可能的情况下使用多样化的电信提供商，暗光纤提供商将边缘站点连接到区域计算设施，并且边缘站点具有通向其他区域的冗余链路。“在可能的情况下”是一个重要的限定词。路由多样性取决于当地市场结构、建筑入口和可用的上游物理路径。两份合同仍然可能共享一条管道、桥梁、交换建筑或长途电缆。
客户进入该网络的入口有独立的设计。Direct Link提供从外部网络到 IBM 私有主干网的私有第 3 层连接，速度最高可达 10 Gbps。该服务对于可预测的延迟、混合应用程序和批量传输很有用，但 IBM 指出冗余并非自动包含。客户需要在多样化的交叉连接路由器上建立两个连接，并且必须配置它们之间的路由。
Direct Link 的先决条件更为直白。IBM 将每个连接称为未受保护的路径。客户向提供商支付连接费用，并承担到达 IBM 接入点所需的交叉连接费用，并且必须决定是在同一位置使用两个路由器，还是在地理上分离的位置。IBM 不会在普通的网络接入点托管客户设备。客户或其运营商拥有从其场所或共置空间到 IBM 分界点的路由。
这意味着两个订单号并非物理多样性的充分证据。IBM 的Direct Link 指南要求独立的交叉连接路由器和客户控制的 BGP 策略。它警告说，等开销路径可能终结在同一路由器上，从而保留单点故障。为了更强的保护，买家必须验证运营商、建筑入口、交叉连接路由器、接入点，并在必要时验证城市多样性。
主干网也可能成为局部性和恢复的依赖项。本地路由将 Direct Link 限制在关联市场；全局路由则开放对其他 IBM 区域的访问。这可以简化第二区域的设计，但它会将更多恢复流量置于长途路径上，并要求客户理解哪些路由和控制变为全局性的。一条私有电路不等同于物理独立的恢复站点，如果两条客户链路在同一管道中失效，第二个区域也无济于事。
多区域并不会在区域消失时移动区域服务器
IBM 的VPC 高可用性指南在平台保护的内容和客户必须构建的内容之间划出了一条关键界线。VPC 控制平面分布在各个区域，并与数据平面分离。即使在客户无法创建或修改基础设施时，现有资源也可以在某些控制平面故障中继续运行。然而，大多数数据平面资源都是区域性的。子网、公共网关、虚拟端点和虚拟服务器都存在于特定的故障域中。
如果一个完整的区域发生故障，IBM 表示该区域中的虚拟服务器将变得不可用，并且不会被移动到健康区域中。其他区域的资源继续运行，区域服务可以保持可用，但客户应用程序只有在其已经分布并能够进行故障转移时才能存活。因此，多区域区域是购买隔离的机会。它并不是在一个区域中配置的所有内容的自动三向副本。
主机故障的范围更窄。在默认的 VPC 恢复策略下，IBM 可以检测到故障主机，将受影响的虚拟服务器移动到同一区域中的可用硬件上并重新启动它。临时数据不会恢复，未保存的写入可能会丢失。这种保护还假设该区域中仍然有合适的硬件可用。它从主机故障中恢复机器；而不是从区域或地区故障中恢复应用程序。
存储遵循其自身的边界。块卷使用冗余硬件，但 IBM 警告说，区域灾难或多个硬件故障仍然可能使卷不可用。快照保存在区域 Object Storage 中，并且可以在另一个区域中创建卷。跨区域快照副本可以支持更广泛的恢复，但恢复并非即时。IBM 表示，将 3 TB 卷的完整副本复制到另一个区域可能需要长达 12.5 小时，并且正常恢复可能会在数据复制到新卷时以降低的性能运行。
裸机具有较少的自动保护。IBM 表示，VPC 裸机服务器上的本地磁盘不支持其快照机制，将备份和恢复留给客户。经典裸机文档类似地表示，IBM 不对客户设备执行备份；账户用户必须启动计划性或一次性备份。专用机器消除了处理器上的嘈杂邻居共享，但使得硬件更换、本地存储和恢复准备更加显而易见。
公开事件档案还包含跨越简单物理边界的故障。它列出了 2025 年 6 月影响多个区域访问和管理云服务的故障、2022 年 6 月所有区域客户遇到的可用性问题、2023 年 10 月的控制台中断，以及 2021 年 6 月的 VPC 私有 DNS 事件。这些报告并不意味着每个运行的工作负载都失败了。它们表明管理、命名和共享服务依赖关系可能具有与机架或区域不同的影响范围。
IBM 的一般韧性文件承认了这种结构。全局服务在整个资产中处理身份、账户、计费、目录和支持功能。某些服务控制功能，包括经典基础设施管理、IP 地址管理、DNS、Transit Gateway、Direct Link 和 Object Storage 的配置，具有全局组件。IBM 将这些设计为冗余运行，但影响其托管区域的事件可能会损害其他位置的管理操作。现有的数据平面可能继续提供流量服务，而新的服务器、路由更改或恢复操作却被阻止。
这是对恢复架构的严峻考验：不是主要应用程序是否继续处理普通请求，而是管理员能否在同一事件期间进行身份验证、分配地址、配置容量、更改 DNS、附加存储和提交支持案例。一个温备用第二站点减少了对紧急配置的依赖。一个假设在广泛事件后每个控制功能和配置文件都仍然可用的冷备计划则承担着更多的执行风险。
支持、计费和生命周期决策也是基础设施依赖
当硬件、路由或控制功能出现故障时，恢复依赖于能够访问相关系统的人员。IBM 提供多个支持级别，而它们之间的差异在运营上意义重大。其支持严重性表将严重性 1 定义为服务中断或无法运行的业务关键功能。高级支持的目标初始响应时间为少于 15 分钟；高级版目标为一小时；基本版则没有初始响应时间目标。IBM 强调这些是目标而非保证，并且客户必须让技术人员随时待命，以便在严重性 1 案例上进行持续工作。
计费、发票和销售案例被排除在这些响应目标之外。这个细节很重要，因为计费可能会影响服务层。IBM 的Direct Link 故障排除页面指出，由于未及时付款，私有连接可能会进入暂停状态，并引导客户寻求支持。其 VPC 文档表示，当资源因违反条款而被暂停时，暂停的虚拟服务器和裸机系统将关闭电源，并且无法使用或修改。这些是不同的情况，但都表明账户管理可能会影响网络和计算的可用性。
IBM 发布了针对高可用性配置的服务水平目标，包括对 VPC 为 99.999% 和对云网络为 99.9999%。SLO 页面明确指出，目标并非保证，也不会触发积分。独立的服务水平协议说明描述了当所覆盖服务未能达到其合同可用性目标时，对费用的积分。无论是目标还是积分都无法修复损失的收入或重建数据。买家需要检查适用的服务描述、所需的拓扑、排除条款和索赔程序，而不是将百分比转换为假定的应用程序正常运行时间。
生命周期决策可能与中断一样具有物理影响。IBM 表示一些较旧的数据中心无法升级，必须关闭。其当前的现代化通知计划钦奈的 CHE01 于 2027 年 6 月 10 日停止运营。新的配置将逐步受限，平台服务有一个更早的迁移截止日期，IBM 警告说没有延期可用。该公司引导客户转向更新的钦奈和孟买多区域区域。
这并非 IBM Cloud 正在从印度撤退的证据。这证明了一个数据中心代码并非永久不变。建筑电力密度、网络设计、设备年限、房东条款和升级可行性最终会改变经济答案。IBM 可以在增长的市场中添加 DAL14，同时关闭一个据称不适合现代化的钦奈站点。客户承担着跟随这些资产决策所需的应用程序工作。
因此，运营关系比正常运行时间更广泛。它包括支持权利、准确的计费联系人、采购订单和信用卡的连续性、预留承诺的续订、对服务终止通知的认知，以及在其他地方重建所需的足够前置时间。一个无法查看发票、批准容量或接收服务通知的云管理员，即使每台服务器都处于健康状态，也可能成为单点故障。
恢复是一项容量和数据移动的实践，而非一个勾选框
IBM 建议将可扩展应用程序分布在负载均衡器后方的各个区域，并使用另一个区域进行灾难恢复。它提供跨区域快照副本、文件复制、Object Storage、基础设施定义和 API。但其 VPC 指南将区域恢复行动分配给了客户：在可用位置创建资源，恢复数据并重定向应用程序。它建议客户将配置保留在故障区域之外，练习步骤，并考虑预配置资源以确保可用性。
预配置值得强调。区域事件可能会在恢复市场中对相同服务器配置文件产生相关需求。一个未经测试的计划可能会发现配额过低、某个配置文件不可用、一项关键服务缺失、Direct Link 仅到达本地市场，或者快照副本仍在移动中。为温备用容量付费在正常运营期间似乎效率低下，因为它的价值在于在异常期间无需争夺库存的能力。
Object Storage 展示了一个产品名称如何包含不同的物理韧性。IBM 表示数据被加密、纠删编码并分散在三个位置，但这些位置之间的距离取决于所选的类。其存储桶指南区分了跨区域存储（分散在大都市区域）、区域存储（分散在单个都市区域）和单数据中心存储（分散在一个站点的各个设备）。客户在创建存储桶时选择位置和韧性。
存储桶不能简单地重新标记到另一个位置。IBM 表示更改位置需要创建一个新的存储桶并移动数据。其复制指南使用开源的 S3 兼容rclone工具，但警告说存储桶设置和对象元数据并非全部自动复制。加密、保留、归档行为、访问策略和其他特性必须重新创建和验证。当传输在 IBM 基础设施上运行时，私有端点可以避免一些网络出口费用。
块存储同样受限。跨区域快照在稳定后是一个独立的副本，但第一次传输是完全的，较大的副本需要更长时间，并且会对传输和目标存储收费。快照文档指出，在每个区域中只能存在一个特定快照的副本。一致性组不能作为组进行复制，因此多卷应用程序的写入一致性和恢复顺序需要单独关注。
从经典到 VPC 的迁移增加了架构工作。IBM 的迁移指南描述了在 VPC 中重建等效的基础设施、将 VLAN 重新映射到特定区域的子网、重新创建安全性、附加新存储、移动数据和更新 DNS。配置文件更改需要停止并启动 VPC 服务器。这是一次受控的重建，而不是对旧机器的实时重新标记。
对于数据本身，IBM 估计使用rsync复制 1,000 GB 可能需要 2.5 小时到超过 12 小时，而数百万个小文件可能需要数天。其经典数据迁移指南将这一范围归因于文件数量、磁盘性能、网络容量和使用情况。在最终切换期间，应用程序可能需要写入冻结、增量同步和回滚决策。状态越大，迁移就越成为一项带宽和业务连续性项目。
离开 IBM Cloud 也因服务而异。Object Storage 提供 S3 兼容的导出界面，并记录了数据可移植性，但 IBM 将替代基础设施、应用程序更改、配置转换和传输执行的责任分配给客户。裸机操作系统和开放式应用程序栈原则上可以移植，但仍然依赖于 IP 地址、设备许可证、网络假设或 IBM 特定的服务。
IBM 的当前条款增加了特定司法管辖区的救济。其云条款页面指出，计划移出数据的欧盟客户可以根据《欧盟数据法案》获得减少的出口费用，而法国的客户可以根据法国 SREN 法律申请免除出口费用。这些权利可以减少退出的一个成本；它们并不能减少数据量、应用程序耦合度、验证时间或对目标平台的需求。
因此，实际的可移植性测试是在主账户之外进行实际恢复，对于关键系统，则是在提供商之外。组织能否从其控制的内容中重新创建身份、密钥、DNS、网络策略、机器镜像、数据库和监控？最大状态传输需要多长时间？哪些特性在目标位置会消失？一次成功的文件下载证明了字节的拥有。它并不能证明服务恢复。
本地数据并不会让所有运营依赖都成为本地
IBM 的数据驻留指南指出，提供给区域和区域性服务的客户内容会在选定区域内本地存储和处理。它还说加密的备份可以保留在该位置。对于选择某个国家或都市区域来处理受监管或延迟敏感数据的组织来说，这是一项有意义的承诺。
同一页面区分了客户内容和账户元数据。业务联系人、使用信息和其他客户元数据可以在区域或全局控制平面运营的地方进行存储和处理。全局韧性文档将账户管理、身份、计费、目录和支持功能置于各个区域之上。因此，区域选择仅在该服务所定义的范围内回答服务内容在哪里运行。这并不意味着每条日志、凭证交换、支持记录或管理操作都保留在同一边界内。
支持访问是另一层。IBM 允许账户所有者启用欧盟支持服务，该服务将工单路由到欧洲支持团队，并在一般情况下将服务交付限制在该区域。IBM 仍然表示，当欧洲团队无法解决案例时，可能会联系欧盟以外的团队，但需经过欧盟审核、提供有时限的访问和隐私控制。该设置改善了运营本地性；它并非一个绝对声明，即欧洲以外的专业知识永远不能参与。
韧性可能与严格的本地性背道而驰。一个区域 Object Storage 存储桶将数据分散在一个都市区域内。跨区域类或远程快照增加了地理隔离，但将数据放置在其他位置。将法兰克福的工作负载复制到伦敦会跨越欧盟边界；将其复制到马德里可能仍在欧盟内部，但引入了第二个国家管辖权和不同的网络路径。公司必须选择一个既满足危害隔离又符合法律规则的恢复地理区域。
单园区区域加剧了这一问题。一个大阪或蒙特利尔的部署可能满足国家驻留要求并提供三个区域，但 IBM 警告说园区依赖可能重叠，数据中心灾难可能影响该区域。第二个多区域区域可能提高容灾能力，但需要检查可用的目的地、服务目录和法律处理。驻留是韧性的一个边界条件，而非其替代品。
物理运营商边界也很重要。云提供商可以承诺进行本地处理，同时使用房东的建筑、本地公用设施、外部光纤提供商和全球企业支持。数据主权除了存储位置外，还涉及法律权威和运营控制。IBM 自身在其数据主权页面上解释了这一区别：驻留关注的是数据在物理上存放的位置，而主权关注的是适用的法律。客户应阅读特定于服务的条款，并为其义务获取适当的建议，而不是从城市名称中推断主权。
一个有效的本地性记录应标识物理区域、服务范围、备份位置、控制平面例外、支持设置、加密密钥位置、员工访问规则和恢复目的地。当 IBM 更改服务的区域可用性或关闭数据中心时，还应重新审视。地理位置并非在购买时选择一次就不再变化的字段；它是架构和合同的持续属性。
IBM Cloud 证明了什么，以及认真的买家仍然应该验证什么
IBM Cloud 的运营证据很强。该公司公布了当前设施代码、VPC 到建筑的映射、网络接入点、物理网络设计、库存行为、容量错误、预留、韧性边界、迁移、关闭日期和重大事件报告。其 PeeringDB 记录和长期存在的自治系统独立支持一个活跃的互联网足迹。这远远超出了一个单薄的网站或一系列未经测试的公告。
强有力的证据并不意味着每项声明都完整。IBM 的公开页面并未标明设施所有者、公用设施拓扑、燃料持续时间、已安装的兆瓦数、机架占用率、可用库存、都市光纤管道或每个区域的运营商合同。它们没有公布恢复事件的当前容量余量。甚至全区域区域之间的物理距离也只是作为最小值给出。广泛的架构是可见的；但逐个站点的集中风险却不可见。
对于生产部署，五项确认可以显著改善购买。第一，将账户中的每个逻辑区域映射到其通用物理位置，并区分完整多区域和单园区区域。第二，确认所需的计算、加速器、存储、托管服务和配额在主站点和恢复站点都可用，对于短缺不可接受的情况则进行预留。第三，记录 Direct Link 的运营商、路由器、接入点和物理路由多样性，而不是仅仅计算电路数量。
第四，衡量恢复。复制真实数据，恢复它，配置替换容量，轮换密钥，更新 DNS，并在实际购买的支持计划下记录结果。包括一个场景，在该场景中，控制台或全局控制功能不可用，而现有的工作负载仍在继续。第五，记录退出路径，包括必须重新创建的配置、发生变化的地址、传输吞吐量、出口处理，以及关闭或服务撤销的合同通知期。
这些测试标识了每次故障会影响到谁。单个主机故障可能会中断一个虚拟服务器，直到重新启动。区域事件会影响那里每个未复制的资源。园区事件可能威胁到单园区区域的所有三个区域。地铁运营商中断可能会隔离客户场所，即使 IBM 的云仍然健康。全局身份或管理事件可能会阻止所有区域的管理员。计费暂停可能会禁用私有连接。关闭可能会迫使一个建筑中的所有剩余客户按照固定的时间表进行迁移。
IBM Cloud 的价值不在于这些依赖关系消失。而在于其中很大一部分被暴露为可选择的基础设施，并在一个实质性的服务组织下运营。客户的工作是购买足够的隔离、预留足够的容量，并保留足够的独立状态，以在 IBM 不吸收的依赖关系中存活下来。
这就是为什么区域选择是 IBM Cloud 主张的正确中心，但前提是必须从物理层面来解读。达拉斯不是一个彩色的点。它是一组命名的建筑、特定于账户的区域映射、Pod、库存服务器、电力系统和都市链路。法兰克福不是主权保证。它是一项带有支持、元数据和恢复条件的位置承诺。Direct Link 不是冗余。它是一条私有路径，直到第二条路径、独立的路由器和有效的路由策略使其变得更多。
这张地图是可信的。隐藏在每个点中的责任才是产品。