专有宿主机DDH：从物理独占到合规自证的架构实践

1. 共享宿主机的账，到底该怎么算

做云上架构的同学，这两年应该都有一种越来越强烈的感受：合规和性能的审计要求，已经从"你用什么云"细化到了"你跑在哪块硬件上"。

我最早对这个问题有切身体会，是在帮一家金融科技客户做等保整改的时候。他们有一套核心账务系统跑在云上，用的是常规的共享型云服务器。各方面都挺好，直到合规团队提了一个问题："我们是和哪些客户共享这台物理服务器的？能不能提供物理隔离的证明？"

这个问题当时把我问住了。共享云服务器本来就是说好的"共享"，邻居是谁、跑了什么负载、会不会有噪音干扰，对租户来说就是个黑盒。虽然云厂商有底层安全机制，但在严格的审计语境下，"我不能证明"和"我不安全"是同一件事。

后来接触到的几个案例，包括一些零售企业做PCI DSS合规认证，还有政务类项目做等保三级复测，都卡在了同一个环节：物理层的责任边界说不清楚。审计人员要的不是"我们有安全机制"这种口头承诺，而是可验证、可追溯、可隔离的物理证据。

这时候就需要重新审视一个问题：当"上云"和"合规"这两件事碰到一起，什么样的基础设施形态才能两头都占住？

火山引擎专有宿主机DDH（Dedicated Host）就是在这个背景下开始被我频繁选入架构方案的。它解决的问题非常直接：你还是用云，但物理机器是你独享的。服务器不跟任何其他租户共享，你可以看到这台宿主机上有哪些虚拟机、这些虚拟机跑在什么规格的物理资源上，甚至能控制虚拟机在物理机上的调度策略。

这篇文章我想把这大半年用DDH做合规架构、混合部署和性能调优过程中攒下来的经验整理一下。不为别的，就为帮那些正在被"合规+云原生"双重标准折磨的架构师、运维负责人，提供一份可以少踩坑的参考。

核心落点还是那四个字：物理独占。

2. 从"邻居噪音"到"合规举证"：为什么共享模式在监管场景里越来越吃力

2.1 所有云服务器都在一个物理机池里"拼车"

先打个比方。普通云服务器就像拼车：你坐上车出发，但车上还有别的乘客。大多数时候互不干扰，但极端情况下，相邻乘客的行李可能会挤到你的座位——对应到云上，就是**邻居噪音（Noisy Neighbor）**问题。

邻居噪音的最常见形态是CPU争抢。虽然云厂商有超分比控制和QoS策略，但共享实例的资源调度毕竟是全局的。遇到同一物理机上某个实例跑满CPU，你这一端的延迟曲线就会起毛刺。数据库类应用对这种抖动尤其敏感，一次几十毫秒的延迟尖峰，可能就会引发主从切换或者连接池打满。

更要命的是审计层面的问题。云厂商当然会告诉你"不同租户之间做了严格的隔离"，但从用户角度来看，你拿不出任何证据。安全组、防火墙规则、虚拟网络隔离这些手段，证明的是"逻辑隔离"；可很多行业合规标准（金融、政务、医疗、支付）要求的是"物理隔离"或至少是"可证明的独占"。

2.2 两种典型的合规死磕场景

我碰到过的典型死磕场景有两类。

第一类是PCI DSS（支付卡行业数据安全标准）认证。这个标准对系统组件所在的基础设施有明确要求：持卡人数据环境（CDE）必须和无关系统隔离。如果用的是共享云服务器，你很难一句话说清楚"我这个VM所在的物理机上还有没有其他租户的VM？这些VM是否属于CDE范围？" 审计时这个问题会被反复追问。

第二类是等保或者行业监管要求的**"专机专用"**。比如金融行业的某些交易系统，监管要求核心业务必须运行在独立物理资源上。过去这只能靠买物理服务器自建机房解决，现在有了DDH，相当于在云上直接划出一台物理机给你用，原来物理机的独占性、可控性、性能确定性全都保留，灵活性和弹性还是云的那套。

2.3 物理独占到底"独"在哪

专有宿主机DDH和普通云服务器最本质的区别在于：从你创建实例的那一刻起，这台物理服务器的计算资源、内存资源、存储资源就不参与任何其他租户的分配。你是这台机器唯一的使用者，你在这台机器上可以跑多台虚拟机，但这些虚拟机都是你自己的业务系统，物理层面上不存在"外来户"。

这种独占带来的直接好处有两层：

• 性能确定性：CPU、内存、网络带宽不再面临跨租户争抢。该是多少性能就是多少性能，不会因为"隔壁老王"跑了个定时任务就出现抖动。
• 合规举证能力：你可以明确记录和导出宿主机和其上实例的对应关系，从物理维度说明业务系统的部署边界。审计问起来，回答是"这台物理机只承载我方业务，无其他租户共存"，逻辑上是自洽的。

3. 钻到资源调度层看门道：DDH的隔离机制是怎么实现的

3.1 宿主机和实例的关系，比你想象的更"透明"

DDH的使用逻辑并不复杂：先在指定地域、可用区申请一台专有宿主机，然后在创建云服务器实例时，把实例调度到这台专属宿主机上即可。整个过程和平时创建云服务器的体验一致，只是多了"指定宿主机"这一步。

比较关键的一点是，DDH支持查看宿主机资源的使用情况。你的物理机是2路CPU还是4路，一共多少物理核，当前被你的实例占用了多少，剩余多少可以继续创建实例，这些数据在控制台里都是可见的。此外还可以设置实例的部署策略，比如集中部署还是分散部署——集中部署时实例优先放在同一台宿主机上（适合内网互通延迟敏感的场景），分散部署时实例会分开放在不同宿主机上（适合高可用架构，避免单点物理故障）。

这就在云上实现了原来物理机房的运维体验。你清楚地知道业务跑在"哪几台物理机"上，物理机的资源水位是多少，故障域是多大。

3.2 内存超分带来的规格约束，别踩这个坑

第一次用DDH的时候，我踩过一个不算严重的坑：开出来的实例规格和宿主机CPU核数对不上。

比如你买了一台64核的宿主机，理论上能开两台32核的实例对吧？但如果你同时想要64GB内存的配置，就可能发现资源不够。原因在于DDH默认是关闭内存超分的。普通共享云服务器的宿主机会做内存超分，比如物理机64GB内存，可能卖出80GB甚至100GB的内存规格。DDH不做超分，你买64GB物理内存，就只能用64GB，一丁点都不多。

这其实是个反过来的"陷阱"：从合规独占的角度，这是优点，物理资源精确可控，不会出现超卖导致的OOM风险；但从容量规划的层面，这意味着内存是硬约束。

所以做DDH规格规划时，建议先算清楚业务对内存的峰值需求，再反推宿主机配置。宁可CPU选多核一点，也别抠内存。很多业务（尤其偏Java技术栈的）CPU使用率常年20%-30%，内存却早早打满。如果按CPU核数来买宿主机，大概率内存不够用；如果按内存来买，CPU又严重浪费。这是个需要反复跟业务对数的过程，没有捷径。

3.3 NUMA亲和性：数据库上DDH的正确姿势

DDH上跑数据库类应用，有一个配置项非常值得关注——NUMA亲和性。

简单说，现在的服务器基本都是多路CPU，每颗CPU有自己直连的内存区域。跨CPU访问内存（即跨NUMA节点访问）延迟会比本地访问高不少。对延迟敏感型的数据库实例来说，这个差异在某些场景下能到10%-20%。

在共享云服务器上，你完全感知不到NUMA调度的存在，虚拟机的vCPU可能被分布在不同的物理CPU上，内存访问路径不受你控制。但在DDH上，你是有办法控制这个事儿的，比如通过设置实例的CPU绑定策略，让数据库实例的vCPU和物理CPU core一一对应，不经过任何超卖或漂移。这样实例的性能就和物理机直跑几乎一致了。

如果你的业务跑的是Redis、MySQL、ES这类对延迟敏感的服务，上DDH之后别忘了做一下这些NUMA相关的优化配置。具体到火山引擎DDH的控制台上，留意实例绑定模式相关的参数即可。跑完结果往往很惊喜，P99延迟能明显改善。

4. 合规不是一句"物理独占"就完事：安全组件和补丁管理的实操细节

4.1 专有宿主机不等于"裸奔的物理机"

有些朋友第一次接触DDH，会有一个误解：既然物理机都是我独享的，那是不是意味着我可以像自建机房一样，随便装驱动、改内核、调BIOS？

这里必须澄清一下：DDH仍然是云产品，不是裸金属服务器。你独占的是这台物理宿主机上的计算和存储资源，但宿主机层面（虚拟化层、物理硬件的固件、底层网络）还是由云平台负责维护的。对于使用DDH的租户而言，宿主机对你是透明的。你不需要也最好不要去碰宿主机本身的系统，那是云厂商的运维边界。

这个模式的好处很明显：你既拿到了物理独占的合规性能红利，又不用为硬件故障、物理机补丁、虚拟化层安全操心。云厂商会在后台完成物理机的维护和升级，不会影响你宿主机上的业务运行（前提是你做了高可用设计，有跨宿主机部署的冗余）。

4.2 第三方组件安全合规到底怎么做

再往深一层说。近年来的合规重点除了物理层的隔离，还有一个非常头疼的方向：第三方组件安全合规。简单的例子：你的系统里用了某个开源库，结果漏洞库曝出了高危CVE。审计人员会问：这个组件在哪个主机上、哪个环境里、受影响的范围有多大？

在没有DDH的情况下，回答这个问题往往要动用CMDB、容器镜像扫描、依赖分析工具等一堆东西，才能拼出一个相对完整的影响面。而在DDH架构下，业务系统的物理边界、虚拟资源边界、网络边界三者可以做到对齐。

比如我们可以把一套生产环境完整地放在一台（或一组）专有宿主机上，那么当某个第三方组件存在漏洞时，影响范围就锁定在这台宿主机上的实例集合里。不需要在海量资源池里去捞"哪些实例用了这个组件"，而是直接说"受影响的就是这台宿主机上的这些实例"。配合镜像扫描和依赖锁定机制，整个追溯链路清晰得多。

我去年年底帮一个客户落地过类似方案。对方的合规要求是"无已知高危漏洞"——这个要求说起来轻巧，做起来极其痛苦。因为如果基础设施底层是共享池，你就无法保证"没有其他租户的镜像或组件间接影响到你的网络链路"。但在DDH环境下，物理隔离+实例白名单+组件的镜像扫描三层配合，就能相对轻松地满足验收。逻辑上从"无法证明"变成"可以证明"，这是质的区别。

4.3 DDH和"专有网络"是组合拳，别只买一半

还有一点特别想提醒：DDH的物理独占，解决的是计算层的隔离问题。但合规是一个体系，网络层面的隔离同样重要。

在实际交付的方案里，DDH几乎总是配合专有网络VPC一起用。DDH上的实例只挂载在指定的VPC和子网里，不暴露公网IP，访问全部走内网或者经过统一的网关。这样一来：

• 物理层：宿主机独占，无跨租户物理资源共享
• 网络层：VPC隔离，无跨租户二层网络互通
• 数据层：云盘加密、密钥管理，实现存储层面的加密保护

三层叠加，才算形成一条相对完整的合规链路。只买DDH但网络还是公网乱挂，合规上也站不住脚。

5. 不止为合规：DDH在AI大模型微调和混合部署里的意外收获

5.1 大模型微调场景下的资源稳定性焦虑

之前关注到"火山引擎微调""火山引擎AI大模型"这些方向的时候，我意识到DDH还有一个很容易被忽略的适用场景——AI大模型微调。

做模型微调和训练的人都知道，最怕的就是显存和内存抖动。虽然大模型训练通常用的是GPU裸金属或者容器集群，但那些预处理、清洗、tokenize、小规模微调这些环节，往往跑在高配CPU机器上。如果这些CPU机器是共享实例，一旦遇到邻居争抢资源，数据预处理的进度就不稳定，进而拖慢整个训练pipeline。

DDH的价值在这里体现为资源水位可控性。你自己的宿主机，所有核都归你，训练任务什么时候跑、跑多久、占多少资源，完全由自己调度。配合火山引擎的AI平台使用，数据预处理、微调评估这些环节可以稳定地跑完，不会被基础设施层拖后腿。

而且从合规的角度来看，模型微调过程中涉及的数据往往比较敏感（比如企业内部知识库、用户行为数据）。把这些数据处理任务的载体放在DDH上，意味着数据的处理环境具备物理隔离属性，这在数据安全审计中是重要的加分项。

5.2 SQL Server和其他带License约束的软件上云

DDH的第二个隐藏优势，和软件许可（License）有关。

很多商业软件（包括SQL Server等）的授权方式是按物理核数或者物理处理器来算的。你用共享云服务器，VCPU是虚拟的，按照云厂商的实例规格去买授权，常常会产生额外的成本。而在DDH环境下，你可以清晰看到物理CPU的型号和核数，并且这些物理资源是独占的。这就让"按物理核授权"类软件的成本核算变得可控且规范。

有企业用户专门为SQL Server上了DDH，目的就是不想让授权费变成一笔糊涂账。

5.3 混合部署：一部分上云一部分物理独占，架构弹性最大化

再聊一下混合部署场景。

多数企业的真实状态是：一部分业务可以跑在便宜的共享实例上（比如开发环境、测试环境、非核心的前端服务），另一部分业务必须跑在资源独占的物理机上（比如核心生产库、敏感数据存储、合规审计范围内系统）。在没接触DDH之前，这种混合需求意味着要么全量买物理机，要么在合规与成本之间做妥协。有了DDH，架构就成了"共享实例打底，DDH兜底"，两者在同一个VPC和账号体系下协同工作，运维复杂度没有明显增加，成本却做到了按需匹配。

我的习惯是：先给业务分类，按合规等级和性能敏感度打标签，合规要求最高的上DDH，普通业务留在共享实例里。这样既保住了合规底线，又没有盲目地把所有负载都赶到DDH上烧钱。

6. 实际上手DDH的部署细节与避坑清单

6.1 从选择到创建的完整步骤

如果你决定尝试DDH，完整的上手流程大概是这样的（以火山引擎云平台为例）：

1. 选择地域可用区：确认目标地域和可用区有DDH库存。不同可用区的物理机型号会有差异，留意CPU平台属性，比如是否支持特定的指令集。
2. 确定宿主机规格：按业务的内存峰值、CPU核数需求，决定宿主机规格。建议CPU和内存的比例稍微向内存倾斜一点，理由前面已经说过。
3. 申请宿主机：创建成功后，宿主机处于"可用"状态，会显示物理资源总览。
4. 在宿主机上创建实例：可以选择在指定宿主机上创建一台或多台实例。建议结合业务高可用要求决定实例的部署方式（集中部署还是分散部署）。
5. 设置资源释放/回收策略：如果宿主机上的实例全部释放，宿主机本身是否需要保留？这个需要提前跟运维团队约好，避免资源空置产生不必要的成本。

6.2 容量规划的算账方法

这里分享一个自己用的算账方法。假设你有三个核心业务模块，每个模块的生产规格是8核32GB。如果放在共享实例上，那就不用考虑物理机层面的容量。但如果你要全部放进DDH，需要怎么算宿主机？

先算内存：3个模块 * 32GB = 96GB。为了保证余量，宿主机内存建议不少于128GB。
再算CPU：3个模块 * 8核 = 24核。看起来32核宿主机就够，但考虑到物理机本身虚拟化层也有开销，以及未来可能扩容，40核以上的宿主机更稳妥。

结果就是，一台45核128GB左右的宿主机，能从容装下这三个模块。我个人的建议是内存预留20%-30%，CPU预留30%-40%。别卡着边界买，不然稍微遇到业务增长，还得再买一台宿主机做迁移，那个成本比多买一台高得多。

6.3 DDH常见误区汇总

我把用DDH过程中见过、踩过的高频误区整理一个表格：

6.4 有一个容易忽略的运维细节

最后重点提醒一个运维细节：宿主机故障恢复计划。

虽然DDH由云平台负责底层硬件维护，但物理机还是有故障概率的。所以你需要确保关键业务在多台宿主机间做了分布，或者在创建实例时启用了宿主机故障自动迁移策略（如果平台支持）。千万别把所有鸡蛋放在一台宿主机上，否则一旦物理机出问题，整个业务就全部停机等待恢复。

根据我个人经验，最稳的DDH架构是"至少两台宿主机+实例分散部署+跨可用区冗余"。虽然多花一点钱，但换来的高可用性和合规完备性，绝对值回票价。

7. 从物理独占走向合规自证

做云架构这么多年，我越来越觉得，"合规"这件事的本质不是去买一个认证标签，而是构建一整套能够自证的系统。在共享云的大池子里，物理层的自证几乎是不可能的；而在DDH的架构里，物理边界清晰、资源归属明确、部署拓扑可控，自证就变得顺理成章了。

这段时间的实际使用感受是：DDH属于那种"平时不觉得惊艳、一到审计和性能压测就真香"的产品。它不会像新的AI服务那样带来炫酷的效果，但在金融机构的年审、支付行业的PCI认证、政务项目的等保测评面前，它就像定海神针一样，帮你扛住了最麻烦的那类问题。

如果你现在正被这些问题困扰——共享实例的资源抖动、审计无法解释物理隔离、第三方组件漏洞影响范围无法收敛、或者商业软件License按核计费算不清楚——不妨认真评估一下DDH。它不一定适合每一台机器、每一个业务，但一定是合规矩阵里最关键的那块拼图之一。

最后再分享一个自己沉淀下来的经验：上DDH之前，先拉一个业务清单，把"必须物理独占""可容忍共享"和"弹性可放共享"三类负载分开，然后只看前两类负载的总资源需求来规划宿主机采购。这样既不会多花钱，也不会在需要物理独占的时候无米下锅。合规不是把所有的资源都锁起来，而是让该锁的锁得足够结实。