CloudHound 测量每一台服务器,按 AWS、Azure、Google Cloud 和 Oracle Cloud 的实时价格定价,并将其迁移到您选择的云。
每条记录都是来自运行中服务器的一个样本:CPU、内存、磁盘、进程和网络流。同一份数据用于对整个环境进行定价、规划和迁移。
一个典型项目的逐日进展。
每台服务器一条命令,或通过 SSH 和 WinRM 无代理采集。清单、进程和连接即刻到达。
CPU、内存和磁盘每分钟采样一次,每台服务器在几分钟内即可得到描述。
每台服务器按 AWS、Azure、Google Cloud 和 Oracle Cloud 实时费率定价:按需、预留和 Savings Plan 并列对比。
五天的网络流被聚类为应用。
根据依赖关系图生成迁移批次计划。可在批次之间拖动应用。
每个批次依次复制、逐块校验、转换并在所选云上启动。在 EC2 上 12 分钟完成 125 台服务器。
创建项目组合时,您可以从十七个托管区域中选择一个。任何国家的代理都通过仅出站的 TLS 向该区域报告,其数据只在该区域处理和存储。
代理以一分钟的分辨率持续记录高精度利用率:CPU、内存以及每个驱动器的操作数和字节数计数器。每台服务器根据连续 7 天的每分钟测量数据,按实测用量确定规格。下面是一台示例应用服务器一周的数据,配置为 8 vCPU、32 GiB 和九个驱动器,其 CPU 和内存曲线根据一台生产服务器的一周数据生成。
经过一周发现后,CloudHound 对一台典型应用服务器掌握的信息。该服务器为示例,但其中每个字段都是代理会采集的。
这是一个示例环境,绘制方式与 CloudHound 根据您服务器之间的网络流量绘制您的环境相同:145 台服务器、780 个连接,按应用分组。拖动服务器,悬停查看它与谁通信,点击应用可单独显示。
CloudHound 识别哪些服务器相互通信,并根据这些流量将它们分组为应用。随后每个应用与其依赖的数据库放入同一个迁移批次,因此不会有系统脱离它所需的系统单独迁移。此示例跟踪 1,000 台服务器从发现到十个批次的计划。拖动可旋转。
CloudHound 以两种方式之一迁移每台服务器。它可以将整台服务器作为经过验证的精确副本重新托管到 AWS、Azure、Google Cloud 或 Oracle Cloud。在 AWS 上,它还可以将服务器的数据库直接平台重构到 Amazon RDS for SQL Server、PostgreSQL、MySQL 或 MariaDB。
CloudHound 支持 135 种操作系统变体,可迁移我们所见在用企业服务器中的 99.5%。
许多迁移到 AWS 的 Windows 服务器运行的是 Microsoft 已不再支持的版本。CloudHound 可在迁移过程中将其升级到 Windows Server 2025,迁移后即获得支持,直至 2034 年 11 月。
块级迁移复制磁盘的块,因此结果是与源一样启动的精确克隆。源服务器从不被修改。读取原始块以磁盘速度进行:在我们的基准测试中,1 TiB 磁盘在 255 秒内复制完成。之后的每次传输只移动发生变化的块,因此最终同步只包含最近的变化。启动前,目标卷会被回读并与源逐块比对,然后调整磁盘大小。以下数据来自一块示例磁盘。
服务器在云端启动后,CloudHound 会检查一切是否已按源端的运行方式恢复:每个服务、端口、数据库、卷和网络路径。
两个问题都不在服务器上。它在 AWS 中所在子网的路由表缺少到两个本地网络的路由。在 VPC 控制台中打开该路由表并添加:
10.20.8.0/2410.20.9.0/24回放我们 2026 年 9 月的基准测试:125 台服务器,涵盖 94 种操作系统版本和 140 块磁盘,共 9.3 TiB,每一台都完成复制、逐块验证、转换、引导,并在 EC2 上确认。
