近两周，深信服千里目安全技术中心先后监测到三起影响广泛的供应链投毒事件—— ● 开源AI API网关LiteLLM在PyPI发布的1.82.7和1.82.8版本被植入恶意代码，在常规安装时即可静默触发信息窃取并横向移动。 ● API协作平台Apifox公网SaaS版桌面客户端遭遇供应链投毒，恶意代码可窃取凭证并远程执行命令。 ● 主流JavaScript库axios的两个npm版本axios@1.14.1、axios@0.30.4被恶意植入远程控制代码。 三起影响广泛的供应链投毒事件分析 AI时代，开发迭代速度大幅提升，企业对开源组件、AI工具链的依赖程度持续加深。攻击者正是利用开发者生态的信任链条发起攻击，潜伏在开源组件、开发工具、部署流程等环节中。 从LiteLLM、Apifox到axios接连爆发的供应链投毒事件中，我们可以看出：供应链攻击已进入常态化、精准化的新阶段，安全风险全面升级。 ● 开发工具软件成为供应链攻击的首选入口。一旦工具被攻陷，攻击者可直接获取系统权限，快速渗透内网，破坏力远超常规攻击，成为AI时代企业安全的核心短板之一。 ● 攻击工具化与精准化是重要趋势。以Apifox投毒事件为例，恶意软件本质上是一个远程代码执行平台。攻击者基于回传的信息筛选高价值目标并实施定制化攻击，整个攻击模式逐步向APT化演进，而常规安全防护手段难以有效抵御。 Part.1 应急响应建议 面对这类攻击，需要警惕的是，目前公开的IoC仅涵盖侦察和凭据采集阶段，绝非攻击的终点。受影响的企业和开发者需要按照“已完全失陷”的最高级别启动应急响应，以免遗漏可能已发生的深度入侵。 ■ 快速排查（IoC） 在网络侧检查是否出现对apifox.it.com、models.litellm.cloud等异常访问； 在终端侧排查litellm_init.pth、/tmp/ld.py，6202033.vbs等恶意留存痕迹。 ■ 全域清除感染 Apifox客户端升级至2.8.19或以上版本（官网下载并覆盖安装）；LiteLLM降级至安全版本1.82.6并锁定依赖；axios退回至安全版本1.14.0-1.x分支或0.30.3-0.x分支。 在防火墙、企业DNS或本机hosts中封锁已知恶意域名；同步清空Apifox本地缓存数据；删除axios相关的木马文件。 ■ 凭证轮换（按优先级执行） 立即重置SSH私钥、Git凭证、云服务凭证AccessKey、K8s集群配置等所有可能泄露的凭证。 Part.2 从「被动修复」转向「主动治理」，重构AI时代的供应链安全防线 实际上，供应链安全风险具有‌系统性、长期性和复杂性‌等特点，仅靠一次临时性、事件驱动的应急响应难以构建持久的韧性。 企业和开发者必须将供应链安全纳入与功能开发同等优先级的体系化建设中，从制度和技术两个维度重构开发工具链信任体系，实现从「被动修复」到「主动治理」的根本转变，从而筑牢AI时代的供应链安全防线。 ■ 从制度层面明确规范 企业和开发者应将安全管理融入研发流程中，通过开发工具沙箱化运行、凭据动态轮换机制、供应链SBOM管理等举措，形成常态化的安全治理体系，以制度约束推动规范化管理，从源头降低供应链安全风险，实现长效治理。 ■ 从技术层面强化保障 此外，为更好地应对复杂多变的供应链攻击，深信服提供一整套解决方案，帮助企业主动守护研发安全—— ● 主动运营，提前发现风险并闭环处置 深信服MSS安全托管服务，7*24小时主动监测风险，主动预警供应链攻击情报并协助用户应急响应，确保用户第一时间获取最新威胁情报并完成内部排查；联动aES终端安全，及时发现隐蔽威胁并实现安全事件闭环处置，有效防范攻击者深度渗透。 ● 主动防御，以快制快，实时拦截新型威胁 深信服AI+SASE赋能的下一代防火墙，通过云威胁情报网关，实时拦截C2外联等新型威胁；通过云端AI智能体，实时挖掘供应链攻击事件并全网共享威胁情报，帮助用户快速发现异常远控等新型威胁。 ● 主动隔离，构建可信可控的研发环境 深信服零信任上网沙箱方案，帮助用户实现业务访问与互联网访问的双重隔离，最大限度收缩攻击暴露面，保障办公与开发环境的可信可控。 欢迎咨询供应链攻击全场景主动防护方案

一、问题描述：使用dellR760xa 服务器搭载4张nvidia-L20显卡安装超融合系统，运行windows2022server虚拟机，显卡直通异常问题现象：1、显卡驱动安装后，nvidia-smi命令报错 2、重启虚拟机后设备管理器中显卡设备异常报错43 3、事件查看器提示显卡被意外删除 4、无法打开显卡驱动控制面板 二、定位问题：1、排查虚拟机环境配置问题，将启动模式修改为uefi，主板设置为q35，更换显卡驱动，但Q35不支持L20的显卡，改为uefi和驱动后依然没有效果。2、将服务器重新安装为物理windows2022server，同时安装驱动，能够安装驱动以及识别显卡，证明硬件无异常 3、重新装回深信服超融合，进入asv后台，查看显卡pci信息（由于是直通场景，超融合没有安装显卡驱动，直接用lspci命令查看显卡）发现显卡的bar内存只申请到了8G，找到关键原因。 问题解析1、什么是 PCIe BAR（Base Address Register）？CPU 想要读写显卡上的显存，并不能直接伸手去摸，必须通过 PCIe 总线在内存地址空间里开一个“窗口”。CPU 看着这个窗口，就能映射到显卡内部的显存。这个窗口的大小，就是你在 lspci 里看到的 size。2、L20 的特殊性NVIDIA L20 拥有约 48GB 的物理显存。当识别为 8G 时：CPU 每次只能透过这个 8GB 的窗口看到一小部分显存。如果程序需要访问整块显存，CPU 就得频繁地“翻页”或切换映射地址，效率极低，且会导致驱动程序架构逻辑冲突。3、现代驱动的要求：对于 L20 这种 Ampere/Lovelace 架构的卡，NVIDIA 驱动默认要求开启 Resizable BAR (Re-Size BAR) 或者直接分配一个大于物理显存的静态窗口（如 64GB）。如果窗口只有 8G，驱动自检时会认为硬件资源不足或分配异常，从而触发 “设备管理器代码 43”。因此在虚拟化直通环境中asv加载的是 vfio-pci这种占位用的存根驱动，只能识别到8G的资源映射表直通给虚拟机，因此在虚拟机主板中，会认为这张显卡就是只有8G，安装驱动时，驱动自检就会报异常43而直接物理安装windows驱动正常是因为nvidia驱动会主动向主板发起动态寻址，向主板申请更大的内存，因此直接安装物理机一切正常。 三、排障思路1、在同型号的ubuntu系统中lspci查看，发现显卡显示的是64G，说明linux内核驱动是支持这个显卡的，怀疑主板配置问题，咨询了dell厂家，该型号默mmiou的bar大小为1024T，完全满足该显卡运行。 2、为了验证是否asv兼容性问题，使用ubuntu桌面体验版进入系统，使用lspci依然是8G，确认是硬件问题导致的。 使用nvidia工具查看显卡状态，发现L20显卡提示可视化功能已打开L20 在这种模式下，会强行开启一种叫“可扩展可视化”的特性。在 NVIDIA 的底层逻辑里，这个特性会要求主板 BIOS 分配一组非常特殊的、非连续的或者受限的物理内存地址。而戴尔 R760xa 的 BIOS 在处理这种请求时，如果不经过特殊配置，就会因为分配不下而退化成最保守的 8G。 /displaymodeselector --gpumode physical_display_disable 通过这个命令从物理硬件层面，彻底禁用所有显卡的显示输出功能。 使用该命令后可看到3个选项，显卡现在的状态就是2导致的。我们选择1将显卡的显示功能关闭。 询问是否全部切换工作模式，选择y 确认后开始执行，所有显卡提示转换成功即可。完成后手动重启物理主机生效 重启后使用lspci -vvv -s 查看显卡状态，看到显卡的bar内存大小已变为64G 重新为虚拟机直通显卡 安装驱动后，虚拟机内输入nvidia-smi可正常看到显卡，问题解决 问题根因： L20 虽然是计算卡，但它底层可能带了一部分虚拟显示控制逻辑（刚才看到的 Scalable visualization 就是证据）。之前的状态：显卡觉得自己要负责“显示输出”，所以它会向主板请求一组特殊的、复杂的 PCIe 资源池。戴尔主板 BIOS 比较死板，一看是显示设备，就只按照老规矩给它分配最保守的 8G。这条命令的作用：它直接改写显卡固件，告诉显卡：“你从今往后就是个纯纯的算力干活机器，把所有显示相关的物理开关全都关掉。结果就是：一旦禁用了物理显示，显卡对 PCIe 资源的诉求会变得极度简单粗暴。主板 BIOS 再次自检时，会发现这只是个纯计算设备，就会毫无压力地吐出那 64G 的完整空间 PS：这个问题真的非常隐蔽，整整排查了3天，觉得很有分享意义

大模型技术飞速迭代，AI能力已深度融入企业研发、客户服务、IT运维等全业务场景，成为数智化转型的核心引擎。 然而，生产级AI应用的建设却常困于一个“魔咒”：效果好必须靠专家。企业高度依赖AI专家团队反复调参，试错成本高、落地周期长、投入不见底，效果难以保障。想要真正破局，就要打破对 AI 专家的过度依赖，让不懂 AI 的业务人员，也能轻松实现专家级 AI 效果。 正是基于这一洞察，SF-FastGPT 应运而生 —— 一款专为企业级用户打造的 “0 专家+好效果”的AI应用构建平台。 深信服 X FastGPT，专为企业级AI应用而生 SF-FastGPT，源自深信服（SANGFOR）与开源平台FastGPT的深度战略合作，将两者的核心优势合二为一。 ▪️ FastGPT：GitHub上超27k星的顶流开源项目 在国内开源社区同类产品排名第二。 凭借强大的RAG（检索增强生成）能力、可视化编排与多源数据接入能力，FastGPT在轻量问答与知识检索中表现优异；复杂业务中可通过工作流灵活编排复杂逻辑，并集成API调用外部工具。被全球开发者广泛用于生产级AI应用构建，经过海量企业场景的实战验证，并保持快速迭代能力。 ▪️ 深信服：深耕AI领域十余年，企业级市场二十余年 自2016年确立“AI First”战略以来，深信服深耕近十载，构建起覆盖“AI安全与基础设施”的全栈AI版图。依托“AI型组织”的实战积淀与顶尖AI人才梯队，持续驱动AI能力进化。 通过安全GPT及安全智能体、企业内部大量场景化Agent应用等复杂场景的最佳效果实践，转化为标准化的产品能力，同时通过大量算法专家的经验沉淀，持续赋能AI算力平台、Agent开发平台及AI原生应用，加速AI能力的普惠化与场景化落地。 同时，深信服依托二十余年服务超十万家政企客户数智化转型的经验，深谙企业级应用的真实业务需求和场景，从而支持构建更贴合客户生产场景的智能体应用。 此次发布 SF-FastGPT 将双方的“顶级AI应用创新能力”与“深厚、普惠的企业级AI应用效果调优”合二为一，从设计之初就只为解决一件事：让没有AI 专家的企业，也能把 AI 真正用起来，而且一开始效果就不错。 从RAG到全栈Agent，打通 AI 落地全链路 ▪️ 不止精于RAG SF-FastGPT延续并升级了FastGPT业界领先的RAG核心能力，覆盖企业知识从治理到应用的全生命周期。通过智能分块、索引优化与检索策略调优，将RAG能力做深做透，在企业知识库、智能客服、AI助理等关键场景，把「知识问答」做到极致，为用户高阶 Agent 应用落地筑牢了可靠的知识根基。 ▪️ 更是全栈Agent平台 在此基础上，SF-FastGPT 进一步提供开箱即用的 Agent 构建、应用测评与企业级平台管理能力，形成从开发到运维的全流程闭环。在低代码、可视化的环境中，业务人员通过拖拽配置，即可快速打造适配自身业务的数智员工、数字分身等场景化应用，极大降低了 Agent 开发的技术门槛，让 AI 真正实现从“对话助手”到“业务执行者”的能力跃迁。 当然，在用户Agent落地的最后一公里环节，SF-FastGPT还配套了相关支撑服务—— 打造了贴合企业真实业务的 Agent 在线 POC 平台，找场景、验证场景、快速部署，均可一站式体验，大幅降低 Agent 的试错成本与落地门槛。 广泛的AI服务商生态，提供覆盖 Agent 落地全周期的陪跑服务，让企业Agent落地全程无忧。 ▪️ 0专家也能保障好效果 SF-FastGPT 之所以能让用户无需AI技术专家，就能轻松落地高质量AI应用，源于两大核心能力的加持—— | 业界领先的知识解析算法 针对复杂文档场景深度优化，精准解析跨页表格、手写体、复杂公式等，从源头确保知识输入高质量，有效提升效果的天花板，真正满足企业级应用的严苛要求。 ➢ 复杂文档场景（含跨页表格、分页、图片表格混合、手写体文字等） ➢ FastGPT深信服商业版对复杂文档的解析效果，远超同类平台 | 效果持续进化的自学习引擎 SF-FastGPT的核心创新，在于将自学习引擎与RAG深度结合。企业知识库准备就绪后，一键触发自动学习，系统自动生成训练样本、完成模型微调。无需算法团队，即可让AI模型从底层深度贴合企业专属业务场景。 首次上线准确率可达85%以上（远超通用Agent的70%平均水平），且越用越精准，让企业AI落地的效果在一开始就有一个更好、更高的起点。 同时，在生态兼容方面，SF-FastGPT做到了极致灵活：硬件上广泛适配英伟达和国内主流算力设备，模型上无缝对接各类主流大模型，模型部署上支持轻量化GB10的算力盒子极简部署，托管云 / 公有云服务、本地私有化部署全场景方案，无论企业IT环境如何，都能快速落地。 不止于此，SF-FastGPT 还与 FastGPT 开源社区版能力同步迭代。每次版本升级，用户都能第一时间获得最新的智能技能和知识检索增强等前沿能力，始终享有最先进的AI能力，保持竞争力。 目前，SF-FastGPT已服务新能源、PCB制造、政府、金融、教育等多个核心领域的数百家企业，成为他们AI应用落地的加速器。 企业AI转型的下半场，真正需要的不是单一的RAG/Workflow工具，而是一个无需专业AI团队就能快速落地生产级AI应用的综合解决方案。 SF-FastGPT 企业级一站式AI应用落地引擎，彻底打破了AI应用的技术壁垒，重构了企业级AI应用的落地逻辑，让AI普惠真正触手可及。 添加SF-FastGPT服务团队，我们为您提供： -免费试用-多套上市企业智能体编排模板免费部署-企业级AI agent应用落地私训课（深圳、长沙、北京、浙江）-企业内训定制课程-Agent技术专家在线咨询答疑

Anthropic在AI安全上砸了数十亿。模型对齐、对抗攻击防护、越狱防范，甚至主导了好几项AI安全行业标准，都做了。结果栽在一个前端入门配置上。 愚人节前，有人在npm公共仓库发现，Anthropic官方发布的@anthropic-ai/claude-code@2.1.88版本安装包里，带了一个完整的cli.js.map文件。这个source map文件里装着全量原始源码，Claude Code打磨了好几年的核心代码，就这么对全世界公开了。没有黑客，没有内鬼，没有供应链攻击。就是一个该在生产环境关掉的配置项，没关。 注：本次泄露的是Claude Code编程CLI工具的前端/Node.js源码，不涉及Claude大模型的权重、训练和推理代码。源码版权归Anthropic所有，未经授权的下载、使用、分发均构成侵权。本文只做事件分析，不提供源码下载指引。 source map为什么能让源码“裸奔”很多人问：一个调试用的映射文件，怎么就导致完整源码泄露了？source map是前端代码编译压缩后的“还原映射文件”。项目上线前，会把成百上千个源码文件打包、压缩、混淆成少量js文件，提升加载性能。source map就是把这些压缩后的代码还原成原始源码的"钥匙"。但这里有个关键区别：只有携带sourcesContent字段的source map，才能1:1还原完整原始源码。这个字段是打包工具的可选配置，开启后会把编译前的全量原始源码直接写入map文件。 普通的source map只是钥匙，带sourcesContent的map文件是连钥匙带保险柜一起给了用户。拿到这个文件，几行脚本就能还原出完整的源码文件、目录结构、变量名、注释、业务逻辑，跟拿到官方源码仓库差不多——差的就是内部提交记录和分支信息。Anthropic的失误在于：生产环境的npm发布包里，既没关source map生成，还把带sourcesContent的map文件直接发到了npm公共仓库。拆解还原的源码：到底漏了什么？有人说，一个CLI工具的前端代码能有多大影响？拆完架构后发现，这次泄露的不是什么简单的命令行工具，而是Claude Code作为AI编程产品的核心运行时平台。泄露的代码库是完整的产品级项目：4471个项目文件，1884个TypeScript/TSX源码文件，覆盖35个一级目录、86个内置命令、42个工具、20个基础服务。 1. 核心执行引擎消息驱动的Agent Loop、QueryEngine对话核心、多轮工具调度逻辑被完整还原。这套支撑Claude Code跑超长会话、复杂多轮任务不跑偏的流程，从设计到代码全公开了。6层上下文压缩治理机制也一并泄露——触发阈值、压缩逻辑、边界规则都在里面。 2. 工具运行时协议统一的工具协议设计、权限控制、安全执行逻辑、并发调度策略全部公开。Bash执行、文件编辑、子代理调用等核心工具的完整实现代码，连同针对prompt缓存命中率的架构设计，都被同行拿到了。 3. 平台化扩展体系Commands、Skills、Plugins、MCP四层扩展体系的设计规则、加载逻辑、动态激活机制、隔离方案全部暴露。竞争对手可以直接基于这套设计搭建自己的AI工具扩展生态。 4. 多运行模式与工程方案交互式/无头/远程/桥接等运行模式的编排方案、启动性能优化、多代理协作、会话持久化、远程会话架构设计，全部透明。这些经过大量用户验证的工程方案，直接拉平了同类产品的研发门槛。 复盘AI行业的几个安全盲区这次事件不是“某个工程师忘了关配置”的偶然事故，背后是AI行业存在的几个安全盲区。重模型安全，轻工程安全AI圈几乎所有的资源和注意力都砸在大模型安全上：模型对齐、对抗攻击防护、越狱防范、数据隐私合规。但AI产品的最终载体依然是软件工程，最容易被突破的防线永远是基础工程细节。投上亿资金防范模型被破解，却不愿花10分钟检查生产环境的打包配置；组建顶尖团队对抗越狱，却连发布前扫一遍产物有没有敏感文件都做不到。 高速迭代下，发布安全给效率让路AI行业竞争激烈，Claude Code作为对标GitHub Copilot的核心产品，需要高频发版。发布环节的安全校验，在"赶版本"的压力下被持续压缩。从还原的源码看，Anthropic的工程团队对启动性能、prompt缓存命中率做了极致优化，工程能力很强。但最基础的发布安全管控出了问题——当团队KPI都绑在"功能能不能按时上线"，没人盯着"配置有没有关对"。前端安全的"灯下黑"source map泄露不是新鲜事。国内头部银行曾因生产环境source map泄露，核心业务系统前端源码完全暴露；头部互联网公司因npm包带source map，核心业务逻辑泄露，甚至被黑产利用。很多创业公司的产品源码也因为同样的原因裸奔过。但直到今天，多数研发团队仍然没真正意识到这个风险： 很多团队为了方便线上排查问题，生产环境开着source map，直接部署到公网 大量团队只在nginx层做了访问限制，npm包、容器镜像里照样带着完整的map文件 不少开发者根本不知道sourcesContent能直接还原完整源码，只把它当调试工具 重事后应急，轻事前防控多数企业的安全体系重心放在“出事后怎么应急”，而不是“怎么从源头不让事情发生”。能制定厚厚的应急响应预案，却不愿在发布流程里加一道自动化安全检测。靠人盯规范，永远堵不住。人会有疏忽，会赶进度，会有侥幸心理。Anthropic不可能没有相关开发规范，但事故还是发生了。前事不忘，后事之师花5分钟做个自检： 生产环境打包时，source map开着吗？map文件随产物部署到公网了吗？ npm发布包、容器镜像里，ignore文件排除了.map文件、源码文件、环境配置文件吗？ 发布流程有自动化的产物安全检测吗？还是全靠工程师手动检查？ CI/CD流水线有发布安全门禁吗？发现敏感文件能阻断发布吗？ 前端代码里有硬编码的API密钥、内部接口地址、prompt模板吗？ 每一个问题都和Anthropic这次事故同源。防护方案分两档：个人/小团队 无强线上调试需求，生产环境直接关source map生成 确需保留的，只生成无sourcesContent的映射文件，不随公网产物部署，只放内网调试服务器或配鉴权访问 在.gitignore、.npmignore、.dockerignore中排除.map文件、源码文件、环境配置文件 每次发布前手动检查打包产物 企业级团队 把source map检测、敏感文件扫描、硬编码密钥排查嵌入CI/CD流水线，检测不通过直接阻断发布 明确生产环境source map使用规则、发布产物准入标准，把安全要求纳入研发流程 定期对线上产物、npm包、容器镜像做全量安全扫描 针对性补齐前端安全、发布安全的认知短板 用自动化管控杜绝这类失误靠人盯规范永远堵不住，那就用自动化。这也是CoStrict在做的事——把安全管控嵌入研发全流程，从源头拦截这类事故。针对人为疏忽导致风险上线的问题：CoStrict的CodeReview CI/CD质量门禁可以自定义扫描npm发布包、前端构建产物中的source map、源码文件、硬编码密钥、敏感配置等风险点，发现异常直接阻断发布针对AI产品核心资产泄露的痛点：CoStrict对AI Agent、Skills、MCP工具、大模型前端应用提供专项检测，识别prompt模板、权限控制逻辑等核心资产的泄露风险。 写在最后AI时代的安全事故，不一定是什么降维打击，也可能是最基础的细节失误。打败你的，不一定是顶级黑客和0day漏洞，也许是忘了关的配置、漏掉的检查、省掉的步骤。看完这篇文章，今天下班前花5分钟查一下你们的生产环境包，有没有不该出现的source map文件。别让打磨了几年的产品，被一行忘了改的配置泄了密。如果你也认同严肃编程理念，欢迎深度参与CoStrict开源建设https://github.com/zgsm-ai/costrict 在 GitHub 上为我们点亮 ⭐️： 每一个 Star 都是我们前进的动力。即刻了解： https://costrict.ai/加入开发者社区： 添加小助手微信，备注 “加群” 与上千位开发者交流实战经验

前言：客户在公有云部署了多台业务系统，需求通过防火墙进行安全防护，实现通过防火墙映射访问业务系统，并通过防火墙代理上网，达到上下行流量经过防火墙安全防护之目的。 一、明确需求背景： 客户为什么要做这个项目？重点是需要切换哪几台ECS ？例如：公有云部署了多台业务系统，实现通过防火墙DNAT映射访问业务系统，并通过防火墙SNAT代理上网，达到上下行流量经过防火墙安全防护的效果。所有的ecs都需要将流量切换到防火墙后进行防护。 详细如图： 二、方案编写思路 三、项目坑点总结 1、客户如果原有是包年包月的普通公网ip，需要先转成按量计费，再转成弹性ip，最后改回包年包月计费弹性Eip的时候存在大量的费用差额，一定要提前和客户沟通好这部分费用问题。（目前已知腾讯云从普通ip转为弹性Eip时有费用问题）差额=新建包年包月计费弹性ip开销-原有普通公网ip转为按量计费的退款 2、腾讯云配置默认路由的时候，需要新建一个VPC路由表，并且不能关联防火墙的WAN口。因为关联WAN口之后腾讯云会将wan口出来的流量又转发给防火墙。但是在华为云和阿里云上，如果内网IP绑定了公网ip，会有更高优先级的VPC路由将流量直接转发至互联网，不存在三层环路问题。 3、在进行变更前预配置的时候，建议配置和DNAT相同的BNAT策略，这样可以在没有改变公有云VPC路由的情况下，进行业务验证。 4、建议vAF在创建的时候，新建2-3个网段用作lan口和wan口，不要与原有的业务子网复用。 ECS虚拟机实例及CLB负载均衡调研表格 公有云防火墙高可用部署参考

目录：一、项目背景 1、部署情况如下 2、两套存储体系 3、业务规模二、现网问题分析 1、稳定性开始出现波动 2、资源已经逼近上限 3、架构复杂度逐渐失控 4、生命周期风险进入临界区三、方案设计 1、整体思路 2、方案取舍过程 3、资源与容量设计 4、业务承载策略 5、存储架构选择 6、双路径迁移模型设计 7、迁移策略设计 四、简要实施过程 1、迁移前准备 2、环境准备 3、迁移工具验证 4、分批迁移策略 5、业务割接与回退 五、关键问题与处理 问题一：vmtools安装失败导致虚机网络异常 问题二：Windows 2008 R2虚拟机迁移后蓝屏且无法关机/关电源 问题三：Windows Server 2008 R2虚拟机启动卡在Startup Repair修复失败 问题四：部分Windows虚拟机无法在系统内调整分辨率 问题五：文件服务器访问延迟波动 六、效果验证 1、稳定性 2、资源使用情况 3、架构变化 4、运维侧变化 七、项目价值总结 1、架构层面 2、稳定性 3、成本与资源策略 4、迁移模型价值八、项目复盘 1、双路径迁移更适合复杂环境 2、分批迁移是风险控制核心 3、文件服务器比想象中更“敏感” 一、项目背景 某客户为会计服务机构，核心业务覆盖财务开票、企业代账、资料归档等场景。原VMware平台不是不能用，而是继续用风险不可控。系统本身不算复杂，但有一个特点：白天不能中断、数据不能出错。一旦异常，影响的是客户报税和开票，业务容错空间比较小。 现网环境搭建时间较早，整体已经运行了接近 7 年。1、部署情况如下 服务器：5台 Dell R740 单节点内存：256GB 虚拟化平台：VMware + vSAN 2、两套存储体系 vSAN存储：每节点2×960GB SSD（缓存）+ 14×1.2TB HDD（容量），集群vSAN原始容量约74TB，实际可用容量约37TB（2副本策略） 外置HP存储（iSCSI方式接入），约7TB 3、业务规模业务在不断增长，目前虚拟机数量在70台以上。 其中几类业务比较关键： AD域控（所有认证依赖） 财务开票系统（核心生产） 文件服务器 Web服务及合作方系统 实际存储占用约54TB，折算有效数据约27TB（考虑副本开销后）。 从资源规模看，这套环境并不算小，但也没有大到必须做复杂架构。问题的关键不在“规模”，而在运行时间 + 架构叠加。 二、现网问题分析 这次改造并不是因为某一次重大故障触发的，而是系统在长期运行过程中逐渐“变得不太对劲”。有些问题单独看都还能接受，但叠加在一起，就开始影响决策。 1、稳定性开始出现波动 历史上出现过两次ESXi紫屏（PSOD），当时恢复过程比较顺利，没有造成长时间中断，但这个问题一直没有彻底定位清楚。这个问题虽未引发长时间业务中断，但已经具备明显的不确定性风险。 2、资源逼近平台上限 集群总内存约1.25TB，但使用情况比较紧张： 日常运行：80%左右 高峰期：存在明显资源争抢 最直接的影响是： 新业务上线需要反复评估资源 部分业务性能波动 一开始考虑过扩容，但很快遇到现实问题： 老型号内存采购周期长 成本明显偏高 投入之后仍然是老架构 扩容变成了一件“投入大、收益不确定”的事情。 3、架构复杂度逐渐失控 存储侧是两套体系同时存在： vSAN（本地） iSCSI外置存储 这在早期是为了扩展容量，但随着时间推移，带来了几个明显问题： 存储路径变复杂（本地 + 网络存储并存） 故障排查需要跨多层（虚拟化 / 存储 / 网络） 一些问题很难第一时间判断归属 实际运维中，经常会遇到这种情况： 一开始怀疑是网络 → 排查后没问题 → 再看存储 → 最后才定位到具体组件 排查路径被拉长，风险也随之增加。 4、生命周期风险进入临界区 7年这个时间点，本身就比较敏感。现场能明显感觉到变化： 磁盘故障更换频率增加（尤其是HDD） 硬件状态不再稳定 厂商支持逐步减少 继续在原平台上叠加投入，风险很难评估。 三、方案设计 这次设计并没有一开始就确定“必须上深信服HCI”。现场其实讨论过一段时间，核心问题是：是继续补这套老系统，还是换一套更简单的架构。 1、总体设计策略最终确定的方向是： 新建一套深信服HCI承载核心业务 原VMware保留，作为过渡与回退环境 采用分阶段迁移，避免一次性割接 这不是“推倒重来”，而是一个相对稳的过渡方案。 2、方案取舍过程方案一：继续扩容VMware优点很直接： 不需要迁移 风险可控 但问题也很明确： 原有架构复杂度不会下降 历史问题（PSOD、存储结构）仍然存在 后续还要继续投入 这条路更像是在“延长使用寿命”。 方案二：新建HCI（最终选择）优势在于： 架构收敛（计算 + 存储一体） 运维路径更短 后续扩展更简单 更关键的一点是：可以把复杂度“清掉一部分”，而不是继续叠加。 最终选择新建 HCI，再通过迁移完成过渡。 3、资源与容量设计 新平台采用： 深信服 aServer-X5-2105 × 2 台 资源配置： 单节点内存：512GB 集群总内存：1TB 存储：6×3.84TB SSD / 节点（全闪） 集群原始容量约44TB（双副本后可用约22TB） 4、业务承载策略 一开始并没有打算“全量迁移”。现网有效数据约27TB，如果全部迁入： 容量压力较大 成本不合理 最终做了拆分： 核心业务（约7TB）迁入HCI 非核心业务继续留在原平台 这样处理之后，新平台负载控制在约30%~50%，同时预留了扩展空间。 5、存储模型选择 在方案设计阶段，对两种路径进行评估： 方案 优点 缺点 混合架构（SSD+HDD） 容量大 随机IO性能不稳定 全闪SSD架构 高性能成本较高、容量受限 结合实际业务： 文件服务器：大量小文件随机读写 财务系统：数据库事务型IO 在经验判断中，混合架构有一个明显问题：一旦缓存命中下降，HDD会成为瓶颈，尤其是在并发访问时，延迟会放大。 最终还是选择了全闪架构，核心考虑不是“性能极致”，而是：让性能更稳定、可预期。 6、双路径迁移模型设计 在迁移方案设计阶段，迁移方式并不是一开始就确定的，而是结合现网条件、授权情况以及迁移风险做了实际取舍。 现场主要评估了两种路径：VMware纳管迁移 和 SCMT迁移工具。（1）VMware纳管迁移通过HCI平台对VMware集群进行纳管后，可以直接调用生命周期管理中的迁移能力，将虚拟机从VMware侧迁移到HCI平台。这个方式的特点很直接： 不需要额外部署组件 不依赖Agent 操作路径相对简单，适合批量迁移 但在进一步评估时，也发现几个限制： 部分老旧虚机（尤其驱动、硬件版本较低）兼容性不稳定 一旦迁移过程中出现异常，可调整空间有限 （2）SCMT迁移工具SCMT本质上是一个独立的迁移工具，支持P2V / V2V场景，可以通过Agent方式完成数据同步和业务切换。相比纳管迁移，它的特点更偏“稳”： 支持全量 + 多轮增量同步 业务中断时间可以控制（分钟级） 对操作系统和环境兼容性更强 在测试过程中，Windows和Linux虚机都可以正常完成迁移，启动成功率较高。 但它也有比较现实的限制： 需要单独部署组件 依赖授权（本项目通过测试授权验证） （3）最终取舍：双路径并行 结合客户实际情况，这里做了一个比较“务实”的选择： 优先使用VMware纳管迁移作为主路径 原因是现场未采购SCMT正式授权，同时纳管方式可以覆盖大部分标准业务 SCMT作为备用路径引入（测试授权） 主要用于应对迁移过程中可能出现的兼容性问题或失败场景 这样形成一个比较清晰的策略： 能用纳管的，优先走纳管； 纳管不稳定或失败的，再切SCMT处理。 （4）现场经验这个决策背后，其实有一个很现实的考虑： 在多业务环境下，迁移的不确定性往往不在“工具本身”，而在： 虚拟机历史版本差异 驱动及系统环境 存储结构差异 7、迁移执行策略 所有虚拟机统一采用三阶段迁移： 全量同步 多轮增量同步 最终切换 在实际执行中，大多数业务中断可以控制在： 3～10分钟（特殊情况例外） 四、简要实施过程整个实施周期控制在两周左右，没有做“大批量一次性迁移”，而是拆开执行。1、迁移前准备 主要做了几件事： 梳理70+虚机清单 标记业务依赖关系（重点关注AD、财务系统） 整理VLAN、IP规划 统计迁移数据量（约7TB核心数据） 在梳理依赖关系时，有一个比较直观的感受：AD一旦出问题，所有系统都会受影响 所以后面迁移顺序是围绕这个来设计的。 2、HCI、SCMT环境准备 完成集群初始化 计算、网络、存储配置与调优 部署SCMT虚拟机 这里有个关注点： VMware、HCI网络打通（确保迁移链路稳定） 3、迁移工具验证 在正式迁移前，单独对SCMT做了一轮验证。当时的目标很简单：不追求快，只确认“能不能用”。 测试结果： Windows / Linux都能正常迁移 启动成功率100% 单台切换时间约5分钟 做到这一步，其实心里就比较有底了。 4、分批迁移策略 迁移顺序不是按“重要程度”，而是按“影响范围 + 可控性”来排的： Web、打印服务 → 先做验证 文件服务器 → 中间阶段（重点观察） AD、财务系统 → 最后迁移 这里有一个取舍：文件服务器虽然不是最核心，但用户感知最明显，所以放在中间阶段处理。 5、业务割接与回退设计 割接统一在夜间窗口执行。流程相对固定： 完成最终增量同步 停止源端虚拟机 启动HCI侧虚拟机 回退策略做得比较保守： 源虚机不关机 仅断开网络 出现问题可以快速恢复 整个迁移过程中，这套回退机制没有真正用上，但在现场非常关键——有回退，执行起来心里更稳。 五、关键问题与处理这次迁移整体过程是可控的，但并不是完全“顺滑”。 真正有价值的，反而是中间遇到的这些问题。 问题一：vmtools 安装失败导致虚拟机网络异常现象 个别虚拟机迁移完成后，系统可以正常启动，但网络始终不通。 现场第一反应是比较常见的方向： 虚拟网卡类型是否兼容 但检查下来，配置本身没有明显问题。 排查过程 一开始的判断其实有点“惯性思维”——优先怀疑驱动兼容。 尝试过： 更换虚拟网卡类型 问题依然存在。这时候才把关注点从“虚拟化层”往系统内部转。 继续排查vmtools安装日志，发现报错：Error: copy file success but the file is not the same! Please retry.Install Update module failed! 当时翻了下support故障案例，发现有个因boot分区、导致scmt客户端安装失败问题： “对于linux要求linux的boot区分空间至少要有200M，其他分区也不要有占满的情况”，因此接下来也尝试往这个方向排查。 根因定位继续往系统层看，发现一个细节： /boot分区使用率已经接近满 进一步分析后确认：vmtools安装过程中需要写入引导相关文件/boot空间不足时： 文件写入不完整 校验失败 安装流程中断 最终导致：驱动未正确加载 → 网络异常 处理方式处理过程反而比较简单： 清理 /boot分区无用文件 释放空间 重新安装vmtools 处理后： 驱动正常加载 网络恢复 经验总结：这个问题本身不复杂，但有两个点比较典型： 迁移问题不一定出在“迁移工具”或“虚拟化层” 系统内部环境（尤其是分区空间）很容易被忽略 在后续迁移中，针对 Linux 虚机，额外增加了一步检查： 提前确认/boot、/、/var等关键分区空间 避免同类问题重复出现。 问题二：Windows 2008 R2 虚机迁移后蓝屏且无法关机/关电源现象在一次纳管迁移完成后，一台 Windows Server 2008 R2虚拟机启动过程中出现蓝屏。 这台机器的问题比较典型但也比较棘手，不是单次蓝屏，而是进入了自动重启循环： 系统一启动即蓝屏 随后自动重启 无法正常进入系统 现场尝试常规关机、关闭电源都没有效果，虚拟机一直在循环重启。多次尝试后，在开机过程中按F8进入启动选项界面，才把系统“卡住”，从而完成关闭电源操作。蓝屏信息如下： 排查与尝试 初步判断还是偏向迁移带来的兼容性问题，重点怀疑方向包括： 虚拟硬件环境变化 磁盘控制器类型变化 系统驱动不匹配 现场没有第一时间更换迁移方式，而是先尝试做一轮基础修复，看能不能在原路径上恢复。 由于系统无法正常启动，这里通过挂载PE的方式进入系统进行处理，主要做了几步尝试： 尝试进入安全模式（未能成功进入） 通过PE环境对系统盘进行修复，排除明显的文件系统异常 整体过程没有报明显错误，但修复完成后，系统依然在启动阶段蓝屏，没有实质改善。 处理方式 到这一步，其实有两个选择： 继续在系统层做更深入的修复（如驱动替换、启动项调整等） 或者直接更换迁移路径 结合当时现场情况，这里没有继续在系统层“往深挖”，而是选择切换方案： 使用SCMT对该虚拟机重新进行迁移 迁移完成后再次启动，系统可以正常进入，未再出现蓝屏问题。对比来看，SCMT在迁移过程中会对目标虚拟机进行驱动适配处理（包括磁盘控制器驱动注入），对原系统环境依赖更低，因此在老系统场景下成功率更高。 经验总结这个问题不算复杂，但在迁移场景中比较典型，主要有几个点：1、老系统对底层环境变化更敏感像Windows 2008/2003这类系统，驱动体系较老，对虚拟硬件（尤其是磁盘控制器）的变化适应能力有限，一旦环境发生变化，就容易在启动阶段出问题。 2、迁移问题不一定都适合“修”从结果来看，这台虚拟机本身是正常的，问题更多出在迁移后的环境适配。如果一直停留在系统修复路径上，时间成本会比较高，而且结果不确定。 3、切换路径比持续修复更有效这次处理没有在原路径上反复尝试，而是直接更换迁移方式，从结果来看效率更高，也更可控。在多业务迁移场景中，这种方式更容易保证整体节奏，不会因为单点问题被拖住。 总结：在类似场景中，如果出现“启动即蓝屏 + 安全模式无法进入 + 文件系统无异常”，可以优先考虑存储控制器或驱动兼容问题，而不是继续从系统损坏角度排查。问题三：Windows Server 2008 R2启动卡在Startup Repair修复失败现象：在迁移完成一台Windows Server 2008 R2虚拟机后，系统启动阶段直接进入自动修复流程，界面提示：该过程持续较长时间后，最终提示修复失败：随后系统进入“发送错误报告 / 关闭”选项界面，但无论选择何种方式，均无法正常进入操作系统，虚拟机持续停留在修复与重启流程中。 排查过程 从现象来看，首先考虑的是磁盘或文件系统异常，因此优先按传统思路进行了验证，包括： 检查虚拟磁盘是否存在明显异常提示 尝试进入安全模式（未能成功） 通过挂载PE环境对系统盘进行硬盘修复操作 但排查结果： 文件系统无明显损坏 无法定位到具体坏道或逻辑错误 同时，系统在修复阶段并未给出明确错误码，属于“修复过程卡住但无明确报错”的状态。 处理判断在排除磁盘与文件系统问题后，问题开始转向迁移适配层面进行分析。 结合前期类 Windows 2008 R2虚拟机的迁移情况，判断该问题更可能与以下因素相关： 迁移后虚拟硬件环境变化（磁盘控制器 / 虚拟显卡类型） 老版本操作系统启动链路对虚拟化环境兼容性较弱 自动修复机制在检测异常启动链路时进入循环修复状态 该类问题的特点是： 系统本身并未损坏，但无法完成正常启动初始化流程。 处理方式在尝试常规修复路径无效后，未继续在系统层深入排障，而是直接切换迁移方式： 使用SCMT对该虚拟机重新执行迁移流程 采用重新同步 + 增量切换方式重建虚拟机环境 迁移完成后，虚拟机启动正常，不再进入Startup Repair流程，系统可直接进入登录界面，业务恢复正常。 经验总结该问题在现场属于“启动修复循环失败”场景，在Windows Server 2008 R2这类老版本系统中较为常见。 从处理结果来看，问题并不在于磁盘或系统文件损坏，而更偏向于： 虚拟化环境变化后引起的启动链路异常 自动修复机制无法正确识别虚拟硬件状态 老系统对迁移后驱动与启动顺序敏感 在类似场景中，如果已经排除文件系统损坏但仍无法正常启动，继续进行系统层修复的收益较低，优先考虑通过重新迁移方式重建运行环境，往往比“修复系统”更直接有效。 问题四：部分Windows虚拟机无法在系统内调整分辨率现象在迁移完成后，个别Windows虚拟机（主要为 Windows Server 2008 R2、Windows 7）存在显示异常： 系统分辨率固定，无法调整 显示设置中无可选分辨率或仅支持低分辨率 远程连接体验较差（画面拉伸、模糊） 而同批迁移的Windows Server 2016、Windows 10虚拟机未出现该问题，可正常在系统内修改分辨率。排查过程 初期按常规方向排查：1、VMTools 状态检查确认虚拟机内工具已正常安装服务运行正常，无报错2、设备管理器检查显卡驱动正常识别无未知设备或驱动异常3、虚拟显卡类型调整尝试更换虚拟机显示适配器类型在Windows Server 2016 / Windows 10中调整后可生效在Windows Server 2008 R2 / Windows 7中无变化 到这一步可以确认： 问题不在工具或驱动，而是与系统版本及底层启动方式存在关联。 根因定位 后续通过support案例检索，定位到一个关键差异： 部分虚拟机采用 UEFI 启动模式 老版本 Windows（2008 R2 / Win7）对该模式下的显示控制支持有限 在该组合下： 系统内无法正确调用虚拟显卡的分辨率调整能力 分辨率控制由固件（BIOS/UEFI）层接管 处理方式针对该类虚拟机，未再从系统内部继续调整，而是直接从底层处理： 进入虚拟机 BIOS / UEFI 设置界面 手动调整显示分辨率参数 保存后重启虚拟机 调整后： 系统内显示分辨率同步提升 远程访问体验恢复正常 经验总结该问题属于典型的“系统版本 + 启动模式”兼容性问题，特点是： 新系统（Win10 / 2016 及以上）基本不受影响 老系统在 UEFI 模式下功能受限 在类似场景中，如果已确认： VMTools 正常 驱动正常 显卡类型调整无效 则应优先考虑启动模式因素，而不是继续在系统或驱动层排查。 对于老版本Windows虚拟机，如采用UEFI启动，建议直接在BIOS层调整分辨率，可减少无效排障时间。 问题五：文件服务器访问延迟现象文件服务器迁移完成后，用户反馈： 日常访问基本正常 但在高并发访问时，偶尔会出现短时间卡顿 这个问题的特点是： 不稳定、不可复现、但用户有感知 排查过程现场第一判断是典型三板斧： 看存储IO 看网络 看资源使用 结果比较“反直觉”： IO没有明显打满 网络无丢包 CPU /内存也正常 一度怀疑是应用层问题，但对比迁移前情况，又基本可以排除。 定位过程后来把关注点放在一个细节上： 存储策略和原环境是否一致 发现： 初始配置使用的是通用策略 没有针对文件服务器做单独优化 虽然资源没有打满，但在并发场景下： 缓存命中率波动 IO调度不稳定 就会放大延迟感知。 处理方式针对文件服务器做了两点调整： 切换为高性能存储策略 优化磁盘分配方式 调整后： 延迟波动明显收敛 用户侧基本无感 经验总结这个问题有一个比较典型的误区：“监控看不出问题 ≠ 用户体验没问题” 尤其是文件服务这类场景： 对延迟敏感 对稳定性要求高 在迁移后，建议优先做一轮： “用户体验验证”，而不仅仅是资源指标验证 六、效果验证迁移完成后，没有立即做结论，而是观察了一段时间运行情况，再做对比。1、平台稳定性迁移前： 存在磁盘老化问题 HDD更换频率增加 出现过PSOD 迁移后： 集群运行稳定，无异常告警 全闪架构下，未再出现磁盘相关问题 未出现主机级异常 现场最直观的反馈是：运维侧“心理压力明显降低” 2、资源使用情况迁移前： 内存长期维持在 80%+ 高峰期存在资源争抢 迁移后： 内存使用率约40%～60% 资源冗余空间明显提升 这带来的变化不是“更快”，而是： 更稳、更有余量 3、平台架构变化 迁移前： vSAN + iSCSI双存储体系 存储路径分散 网络链路复杂 迁移后： 单一HCI架构 无外置存储依赖 存储与计算统一管理 变化的核心不是“减少设备”，而是：故障路径被明显缩短 4、运维侧变化 迁移前： 存储问题需要分别排查vSAN与iSCSI 网络与存储链路需逐层确认 磁盘更换操作频繁 迁移后： 存储统一在HCI平面处理 故障定位路径更直接 外置链路消失 整体变化可以总结为： 从“经验驱动运维” → “结构驱动运维” 七、项目价值总结 1、架构层面 完成从“多套系统叠加”到“单一平台”的收敛。减少了： 多存储体系并存 多路径依赖 系统结构变得更简单，也更可控。 2、稳定性 这次改造没有追求极限性能，而是优先解决不确定性： 老旧硬件风险被消除 磁盘频繁更换问题不再出现 历史隐患（PSOD）不再影响当前环境 3、成本与资源 本次没有做“全量替换”，而是只迁移核心业务（约7TB）这样做的实际效果是： 避免一次性资源投入过高 原平台压力得到缓解 新平台资源使用更集中 资源使用变得更“有针对性”，而不是平均分配。 4、迁移模型价值双路径迁移模型在这次项目中起到了实际作用： 纳管迁移 → 提升整体效率 SCMT → 处理异常情况 相比单一方案： 容错空间更大 迁移节奏更可控 这个模型在多业务环境中是可复用的。 八、项目复盘 1、双路径迁移模型更适用于复杂环境 在虚机数量多、系统类型复杂的场景中： 不确定性来自多个维度（驱动、系统、存储） 单一迁移方式很难覆盖所有情况 双路径设计的价值在于： 出现问题时，不需要“卡住”，可以直接切换路径继续推进 2、分批迁移是风险控制核心 这次没有追求效率，而是优先控制风险： 每一批迁移都单独验证 每一步都可回退 这样做的结果是： 没有出现集中性问题 节奏始终可控 3、文件服务器比想象中更“敏感” 在这个项目中，一个比较深的体会是：文件服务器往往比数据库更容易引发用户反馈问题。原因在于： 用户直接感知 操作频繁 对延迟敏感 迁移这类业务时： 需要更关注“体验”，而不是只看监控

信服智创 | 参与得豆！2026技术征文大赛正式启幕！目录：一、项目背景二、现网问题分析三、方案设计与实现四、实施过程与关键步骤五、效果验证六、项目价值总结 一、项目背景 1.1 企业概况 杭州某供应链企业，主要为上下游合作方提供订单、库存及物流相关系统服务。业务系统数量不多，但均为日常生产核心系统，对稳定性和访问连续性要求较高。 业务经年扩展，外部访问需求逐步增加，包括分支人员、合作方以及移动办公场景。 1.2 现网访问方式 企业于2018年部署SSL VPN作为远程访问入口，整体使用方式较为固定： （1）用户需安装SSL VPN客户端 （2）通过客户端建立连接后接入内网 （3）再通过“域名 + 端口”访问具体业务系统 该模式在早期运行稳定，能够满足基本远程接入需求。 1.3 改造触发因素 本次改造由多方面因素共同推动： （1）设备生命周期到期 现有SSL VPN设备将于2026年进入EOS阶段，后续不再提供版本更新与技术支持，继续使用存在一定风险。 （2）终端环境变化 鸿蒙NEXT系统逐步落地，原有依赖客户端的接入方式在新终端上的适配存在不确定性，需要提前规划替代方案。 （3）设备运行年限较长 设备已运行多年，在稳定性和后续扩展能力方面存在一定隐患。 （4）访问需求发生变化 用户对访问方式提出了新的要求： ·希望能够管控业务系统里的个别模块 ·外部访问与内部访问希望有区分 在上述背景下，企业开始评估新的远程访问方案。 二、现网问题分析 2.1 生命周期带来的运行风险 设备即将进入EOS阶段，现网方案在长期运行上存在不确定性： （1）后续无法获得安全更新与漏洞修复 （2）出现问题时缺乏厂商支持 （3）无法满足持续运行与合规要求 2.2 新终端环境下的适配问题 当前远程访问依赖客户端方式，在传统终端环境下运行稳定，但在新终端体系（如鸿蒙NEXT）中存在潜在问题： （1）客户端适配情况不明确 （2）后续终端扩展存在不确定性 2.3 访问控制能力不足 现网SSL VPN主要解决“能访问”的问题，但在实际使用中，企业管理要求提升，逐步出现以下情况： （1）内外网访问缺乏差异的认证方式 （2）部分业务系统需要限制具体URL路径访问 因此，我们推荐客户引入零信任atrust进行替换SSL VPN。 三、方案设计与实现 3.1 设计原则 （1）不影响现有SSL VPN业务、平滑切换 （2）保持原有业务访问方式不变（域名 + 端口） （3）优先满足当前需求（终端适配、精细化访问控制等等） 3.2 整体方案说明 改造后访问路径与原SSL VPN类似： 用户终端 ↓ aTrust / SSL VPN ↓ 业务系统 业务系统访问方式未改变，仅对访问入口进行替换。 3.3 访问控制实现方式 结合当前需求，访问控制设计保持简化，主要实现以下几点： （1）用户与系统对应关系 ·不同用户访问指定业务系统 ·未授权系统不可访问 （2）内外网访问区分 ·内网访问：保持相对宽松认证策略 ·外网访问：增加二次认证、增强认证等 （3）URL级访问控制 ·对特定URL路径进行访问控制 ·限制部分功能访问权限 3.4 实施方式设计 （1）业务系统保持不变 ·原有访问地址不调整 ·不影响业务系统配置 （2）分阶段切换 ·新访问方式逐步上线 ·用户分批迁移 （3）并行运行 ·SSL VPN与新方案短期并行 ·出现问题可快速回退 四、实施过程与关键步骤 4.1 准备阶段 （1）现网梳理 ·梳理用户、业务系统及访问路径 ·记录原SSL VPN策略和使用情况 （2）aTrust部署 ·完成设备部署 ·完成网络及接入配置等基础配置 （3）网络与出口策略配置（需要客户配合操作） ·配置出口设备端口映射（使用公网IP+新端口），将aTrust的接入端口443与隧道端口441映射在公网，与SSL VPN并行。 ·配置内外网DNS域名解析，确保新访问入口正常解析 ·配置访问策略，允许aTrust设备IP访问业务系统 4.2 配置阶段 在基础部署完成后，进行设备配置： （1）用户配置 对接客户现有AD域用户目录 （2）认证策略 设置内网和外网访问的差异化认证策略 （3）应用配置 ·在aTrust上发布业务系统 ·配置应用访问路径，确保用户通过入口访问业务系统 （4）授权配置 根据用户组配置业务系统访问权限 （5）安全管控策略 配置URL级访问控制，确保关键功能和资源的访问安全 4.3 切换阶段 在策略验证完成后，采用分批切换方式将用户迁移至aTrust新访问入口： （1）按部门或业务系统批次逐步迁移 （2）与原SSL VPN短期并行运行，确保业务连续性 （3）完成全量用户切换后，正式停用原SSL VPN 五、效果验证 5.1 验证项目 （1）用户登录验证：确保所有用户能够正常登录 aTrust 访问入口 （2）业务系统访问验证：确认用户可访问其授权的业务系统 （3）内外网认证策略验证：验证内网与外网访问策略差异生效 （4）URL 级访问控制验证：确认关键路径和受控功能按策略限制访问 5.2 验证结果 （1）用户登录：用户能顺利登录 aTrust，无异常报错。 （2）业务系统访问：用户仅能访问其授权的业务系统，权限控制准确生效。 （3）内外网认证策略：内网访问保持正常认证流程，外网访问的二次认证、增强认证策略均按设计生效。 （4）URL 级访问控制：关键路径和受控功能访问严格受控，未授权访问被有效阻断。 （5）业务连续性：迁移过程中与 SSL VPN 并行运行，用户体验平稳，业务访问不中断。 六、项目价值总结 6.1 安全价值 （1）访问入口统一：用户访问经过aTrust统一入口认证与策略控制 （2）内外网差异化管理：对不同访问来源用户实施不同认证策略 （3）URL级管控：对关键业务功能路径进行精细控制 （4）减少安全隐患：替换即将EOS的SSL VPN，规避长期安全风险 6.2 运维与管理价值 （1）集中策略管理：用户、应用和安全策略在同一平台管理 （2）简化运维操作：不再需在多台设备上重复配置策略 （3）便于扩展：新用户或新业务系统可快速在aTrust发布并管理 6.3 业务连续性价值 （1）平滑切换：分批迁移+并行运行确保业务不中断 （2）稳定访问：用户体验顺畅，迁移期间访问无异常 （3）终端兼容：不同操作系统和终端设备均可访问业务系统 6.4 项目总结 本项目通过aTrust替换SSL VPN实现了： ·安全可控的访问体系 ·集中的策略管理与维护 ·业务连续性与稳定性保障

在大模型商业化加速的浪潮下，全球算力集群建设的爆发导致了 CPU、内存及高速 SSD 等核心硬件产能被大量挤占 。硬件交付周期动辄延长至数月，内存价格暴涨，供应链波动已成为长期变量 。 面对有限的预算和业务必须上线的双重压力，IT 建设该如何破局？ 在这个特殊的供应链承压期，深信服作为各行业用户数智化道路上的坚定同行者，希望以自己在软件定义领域的积累以及创新技术方案，并结合近期与许多用户的探讨，梳理出两条更为从容、能帮助用户跨越周期的应对路径。 适配用户 已有存量服务器资产（无论是使用 VMware还是国产第三方平台，亦或是深信服超融合平台），当前面临资源瓶颈需要扩容，但因为硬件涨价预算吃紧，希望在原预算下实现新业务上线的用户。 很多时候，数据中心的资源并没有真正耗尽，而是在“空转”了。深信服希望帮用户盘活旧资源，让预算花在刀刃上。 第一步：用AI 智能评估，把浪费的资源“抠”出来 我们提供专业的智能资源评估工具与专家服务 。通过机器学习算法，能够精准扫描并识别出底层平台中长期闲置的“僵尸虚拟机”以及过度分配资源的业务 。通过合理的资源腾挪与清理，往往能直接释放出大量可用的计算空间 。 按实际数据（根据近几月市场最新价格）测算：每释放1GB 内存，相当于节省250-300 元采购成本；每释放1TB 存储空间，可节省采购成本 400-500元。这些隐性浪费资源直接变成看得见收益，资源利用率与成本双双优化。 第二步：内存分层创新技术，打破扩容死结在实际运行中，服务器往往是“CPU 还有富余，但内存已经撑爆了”。面对昂贵的内存条，深信服创新“DRAM + NVMe SSD 内存分层技术”， 用户只需在旧服务器上增加一块高性价比的 NVMe 固态硬盘作为“二级内存” ，就能实现主机可用内存直接翻倍！（最大可达） 实测中，一台128GB物理内存的服务器搭配NVMe盘后，可获得接近256GB的内存使用效果，运行Oracle数据库时TPM稳定在2500左右，性能影响极小，但内存容量直接翻倍。 ➢ 开启内存分层前：物理内存容量128G，占用率高达77%；在Oracle性能测试中，数据库 TPM 2700+。 ➢ 开启内存分层后：原本服务器可获得相当于256G内存使用效果；在Oracle数据库性能测试中，数据库 TPM 平均值稳定2500，性能下降幅度控制在10%以内。 深信服内存分层技术通过 DRAM 与 NVMe SSD 的高效组合，在满足业务内存总需求的同时，可显著降低硬件采购成本。在相同硬件配置、内存分层比例设为 1:1 的前提下，分别以 Intel 三代平台（DDR4 内存）与 Intel 五代平台（DDR5 内存）为例，对比纯 DRAM 采购方案与 DRAM+NVMe SSD 组合方案的内存采购成本，具体节省费用如下： 从上表得知：当内存需求越大，这种“利旧”方案的价值就越明显。当内存总需求从128G提升至512G，单台服务器成本节省最高可达7万元，实现了内存性能与采购成本的平衡，为用户带来更高的投入产出比。 可用内存翻倍的背后有哪些技术支撑？ 冷热数据智能分层，全程业务无感 系统自动识别冷热数据——冷数据自动搬到NVMe构建的二级内存，热数据留在DRAM里，全程全自动，业务无感。 实时监控与智能优化，业务不中断 更省心的是，系统实时监控内存冷热置换状态，一旦有异常波动或压力过高，自动触发优化策略，提前规避性能抖动，保障业务连续性。 优化内存交换机制，高峰期稳得住 优化分层场景内核调度与页迁移路径，减少频繁置换带来的性能抖动，高负载下也能稳稳运行。 此外，深信服在底层构建了完备的软件定义可靠性机制（如 HA 2.0、亚健康检测、热迁移等），用软件的冗余算法弥补老旧硬件的物理缺陷，确保盘活后的集群依然能稳定承载核心业务，老设备也能发挥新价值。 适配用户必须要新建IT资源或替换面临退役周期的老旧硬件，但不希望一次性投入巨额采购资金，缺乏专业运维团队，同时对数据安全、物理隔离有严苛要求的用户 。 当存量资源不足以覆盖业务增量，且新硬件采购受阻时，用户亟需更灵活、高性价比的用云新选择——深信服「托管云专属用云解决方案」以“服务化订阅+专属资源”模式，帮助用户快速上线业务，并以严格的专属隔离资源给到用户媲美自建机房的安全感。 | 资金解压：从“重资产买断”转为“按需订阅” 在同等规格下，托管云方案的首年投资较线下自建直降近 60% ，在这个特殊时期，帮用户彻底截断高昂的初期现金流压力 。 | 就近专属，下云无阻力 托管云方案提供的是完全隔离的专属计算与存储资源，可以理解为用户获得的是一朵专属的，在线化的私有云。用户需要时可安心启用资源，不需要时可灵活进退，免费享有上下云迁移服务 ，彻底打消“下云难”的后顾之忧。 | SLA达99.975%，专属管家免运维 云端超200人覆盖8个方向的专业运维团队，7*24小时全栈监控和主动处置，提供高达99.975%的 SLA 和全栈免运维守护，保障客户核心业务稳定可靠运行。 在硬件供给持续不确定的大环境下，深信服坚持以软件定义能力重构资源效率，用技术确定性对冲外部环境的不确定性；以开放兼容的生态，保护用户的每一分现有资产投资，为用户提供真正不绑定、高可靠、低成本的基础设施供给方案。

客户有两个数据中心分别是数据中心A（主用）、数据中心B（备用）。两个数据中心不在同一位置，要实现两数据中心一主一备。平时主用数据中心A，当数据中心A宕机时自动切换到数据中心B。两数据中心的内部运行业务一致且有裸光纤进行实时数据同步。

由于某些原因客户需要将超融合虚拟机（VDI虚拟机）迁移到笔记本电脑。

基金公司作为持牌金融机构，其办公终端上网的安全合规性要求非常严格，用户终端不仅存储着海量的敏感数据，同样也连接着金融专网，因此对于安全的要求是“零容错”’的，没有失败的机会

《新架构网闸高可用配置及HA效果验证案例》 一．需求背景描述1. 网闸作为内外网隔离设备部署在两套防火墙之间2. 当一台网闸设备出现异常，需要进行主备切换快速拉起业务，保障业务连续性3. 主备设备心跳链路需要采用光口双链路聚合，保障设备切换和数据同步4. 需要具备实时监控设备状态能力，以保障主设备故障触发HA机制 二．配置思路1. 根据需求采用高可用模式下的主备模式2. 心跳口使用两个常规业务光口把两台设备直连，并做链路聚合3. 配置心跳口地址，保证心跳口通信4. 由于出厂设备的ID是一样的，先修改设备ID5. 分别启用两台设备高可用功能，配置监控切换条件 三．配置过程1.可以看到设备出厂ID为24tuo6，修改主机为24tuo7，后台更改主机或者备机的id，任意更改一台达到id不一致即可（更改设备后台配置文件涉及进入后台操作请联系400处理）2. 分别配置心跳口链路聚合，配置心跳口IP，并将两台设备直连3. 开启主机集群模式--配置设备信息--开启备机集群模式--配置设备信息--选择一台为主控--选择业务监控口（必须勾选，否则主备测试不会切换）--两台设备配置完成后设备信息都为正常状态（注：选择主控后的设备永远为主控，不可切换角色） 四．效果验证1. 验证双机切换触发HA可以采用的方式（选择其中一种）：①关闭主机电源，②拔掉主机业务监控口物理线路，③DOWN掉对端设备连接网闸业务口的接口2. 测试前使用tcping监控业务连续性，然后采用上述切换方法触发HA，观察丢包情况正常丢4-5个包，同时查看备机代理日志，切换完成3. 继续使用tcping监控业务，将主机恢复到正常状态，此时HA会自动触发，主机自动接管业务，查看丢包情况正常丢4-5个包，同时查看主机代理日志，效果验证完成

原使用一台华为USG6330型号防火墙，做了一些安全策略，导致公司业务系统受到影响，在更新换代的时候，考虑了深信服的防火墙。

客户属性为食品加工制造销售类企业，存在大量直接暴露在互联网的to C业务系统，如官网、商城和经营平台等，这些业务系统基本都使用HTTPS形式发布到互联网，由业务系统自身进行SSL加密，在保证了用户到服务器之间数据私密性、完整性和安全性同时也存在诸多问题

华三防火墙端为分支无公网地址，做野蛮模式，本文分别介绍华三和深信服设备的配置

客户目前SIP内存较高，需要更换成虚拟化的VSIP，后续所有STA及其他安全设备日志对接到VSIP上，因此原始数据需要全部迁移到VSIP上。