非标自动化厂20个SolidWorks席位，两台服务器如何撑起PDM与许可？

前阵子一位做非标自动化设备的同行找我聊起一件挺典型的事：厂里二十多个设计，天天在SolidWorks里画图、改图、出BOM，老板终于批了两台服务器的预算，可他不确定这两台到底够不够撑起来。我当时给的回答是：够不够用，不取决于机器堆得多高，取决于两台服务器怎么分工、怎么配合、怎么管住设计团队的使用习惯。这个判断来自我帮一家非标自动化设备厂从零搭这套环境的经历——两台塔式服务器、二十个设计席位，跑了一年半，整体稳定，也踩了不少坑。这篇文章就把当时的需求分析、服务器分工、配置细节和运维经验完整捋一遍，给准备搞或者正在为这事发愁的同行当个参考。

1. 先把这笔账算清楚：20个SolidWorks设计其实是三座压力山

给服务器下单之前，先得弄清一件事：SolidWorks的渲染计算、模拟分析这些重活，都发生在设计人员自己的工作站上，服务器根本不参与。服务器真正扛的是另外三件事——许可能不能发得下来、文件存不存得下、版本管不管得住。这三座山不看清楚，买再贵的机器也是白搭。

1.1 许可证：一道拦在"启动"之前的坎

SolidWorks的商用授权可以做网络浮动许可，由一台服务器统一管理，客户端启动时都得先找这台服务器要授权，拿到才允许打开软件。20个人的团队，采购时要规划好席位数量：要么按人头买20个同时在线，要么买少一些的浮动池，在高峰期接受短暂排队。这里有个容易忽略的点——许可证服务本身的资源占用极低，但它绝对不能宕机。它一挂，全组所有人都进不了软件，其他机器配置再好都没用。所以它必须放在一台"稳定优先"的服务器上，而不是随便塞进某台设计人员的工作站。

1.2 数据量：一年轻松涨1-3TB的文件仓库

设计团队的文件量往往被严重低估。一个常见的非标设备项目，三维装配体、零件、工程图、STEP/STP中间格式、DXF、仿真结果、评审备份，单项目十几到几十个GB很正常。20个人并行做五六个项目时，一年的存储增量轻松超过1TB，项目大的时候到3TB也不意外。算笔最简单的账：20人 × 250个工作日 × 每人每天平均新增200-500MB，就是1TB到2.5TB的年增长。这还没算备份所需的空间。存放数据的服务器，容量规划必须按"三年业务增长 + 备份余量"来算，不能只盯着今天有几个项目。

1.3 产品数据管理：比"存文件"更值钱的事

比存储容量更重要的是版本和关联关系。做非标设备，改图是家常便饭：周四下午客户改了个需求，五套装配体连带三十几张工程图、两个BOM表全要动。要是设计文件散落在共享文件夹里，最典型的状态就是"方案图_v7_最终版.sldprt""新建文件夹(2)"这种命名，版本全靠人肉记忆。更麻烦的是零件改动后，其他引用了它的项目也会跟着出问题，没人能准确说清哪个版本对应哪个客户。这种混乱靠加硬盘解决不了，得靠PDM系统来解决——管住每一份文件的检入检出、版本历史、修订状态和审批流程，让"不知道哪个版本能发给车间"这句话从团队里消失。这两台服务器里，有一台很重要的角色就是给PDM当底座。

把这三座山分开看，两台服务器该干什么就已经清楚了。

2. 两台服务器的职责切分：一个管脑子，一个管仓库

当时内部讨论时，把整套架构概括成两句话：一台服务器是团队的"大脑"和"门卫"，另一台是"仓库"和"保险柜"。两者的负载特点完全不同，不能混着用。

2.1 服务器A：承载许可证服务和PDM数据库引擎

A机跑两样东西：SolidNetWork License Manager，以及PDM系统需要的数据库服务。PDM系统在非标自动化厂里最常见的是SolidWorks PDM Professional，它的底层结构分两层：SQL数据库记录文件逻辑、属性、工作流状态和版本指针；文件实体本身不塞进数据库，而是统一放到一个叫归档库（Archive）的文件共享目录。我们把数据库放在A机，归档库放在B机，这个设计是有意的——数据库事务主要是随机小IO，文件流主要是顺序大IO，两者混在同一个磁盘组上会互相干扰。A机对硬盘的要求是"稳"，SSD阵列就够；对内存的要求反而高，SQL Server缓存越大，20个人同时查目录、检入检出的响应就越跟手。内存只给16GB的话，人一多SQL查询就会出现明显等待。

提示：PDM数据库如果用了内置的SQL Server Express实例，单个数据库有体积上限，20人团队长期使用很容易顶到上限。预算允许的话，尽量用标准版数据库服务，别在这上面省。

2.2 服务器B：扛起PDM归档存储、共享交换和备份

B机的核心任务是存文件。所有设计文件的实际内容最终都会落进B机的归档目录，20个人检入检出的读写也主要发生在B机上。除了PDM归档库，我们还在B机开了一个"临时交换区"共享文件夹，专门放外发图纸、STEP转档、给工艺和车间的临时文件。这些文件不纳入PDM做严格版本管理，避免把临时文件全塞进库里导致版本记录乌烟瘴气。B机同时承担整网备份：每天夜里把A机的数据库备份和本机归档库快照复制到独立的外置硬盘或离线冷备盘。经过这样的切分，两台机器的负载特点变得很清楚——A机偶尔高内存占用、磁盘IO很轻；B机常年硬盘忙碌、网卡压力大。

2.3 为什么不干脆买一台高配服务器

这个方案刚提出来时，有人直接问：干脆一台高配服务器加一个大RAID组，不更省事？确实能跑，但我不推荐。第一是单点故障，设计团队最怕全员停摆，一台机器挂了，PDM库、归档文件、许可证服务跟着一起瘫痪，那真是全组停工。第二是混合负载带来的体验差，数据库事务和文件流同时抢磁盘IO，CPU看着没满，大家就是觉得打开装配体变慢。第三，备份本身也是资源大户，夜间备份如果和加班画图撞在一起，一台机器会又慢又不稳定。两台机器的本质不是堆算力，而是给不同特性的负载分配不同资源域，顺便把故障半径缩小一半。

3. 非标自动化行业跑不掉的三个场景：外购件库、高频改版、多项目并行

通用方案讲完，得回到非标自动化行业本身。它跟标准化产品工厂最大的区别是：项目定制、周期短、改版频繁。下面三个场景如果不在部署阶段就规划好，后面一定会出乱子。

3.1 外购件模型库：避免20个人重复下载和重复建模

做非标设备，气缸、导轨、电机、传感器、减速机、轴承这些外购件在模型里占的比重相当大。20个设计人员如果各从供应商网站下载模型，或者在自己电脑里存一份，硬盘里很快就会出现几十上百个同名气缸模型，大小不一、版本不一，谁引用的哪份都说不清。我们的做法是在PDM里建一个"外购件标准库"文件夹，全员只读，安排专人或者轮流维护。供应商模型下载后先做整理：统一命名规则、按品牌/型号/规格分类入库、检查特征是否干净，必要时转成中间格式再存。设计人员需要元件时直接从库里拖进装配体，不用再各自找资源。这一条坚持执行，省下的远不止存储空间——很多供应商模型一个就要几百MB，20个人各存一份和共享一份的差距是几GB到几十GB，更别说满世界找模型浪费的工时。

3.2 高频改版和BOM流转：靠版本、标签和审批状态兜底

非标项目的设计周期通常按周算，方案评审、客户修改、工艺调整、车间反馈，每一步都会产生新的图纸版本。不要指望"大家自觉把版本存成不同文件名"，PDM的版本机制才是唯一可靠答案。设计人员每次把改完的文件检入，系统自动生成新版本号，旧版本不会被覆盖，也不会丢失。方案评审节点到了，给相关文件打上"已评审"标签，之后的改动都基于这个状态继续流转。工程图的BOM表可以直接关联PDM里的文件状态，出图时导出的BOM至少能保证填的是当前有效版本。很多厂这一步靠老师傅眼神确认，风险太高了。

3.3 多项目并行时，目录结构和权限不能只管"能打开"

20个设计人员通常不是在做一台设备，而是五六条线同时跑。PDM库的文件夹结构要按"项目编号/阶段/专业"分层，而不是按"张三文件夹/李四文件夹"堆放。权限要分几个层级：项目负责人对本项目文件有完全控制权，其他设计人员对共享标准件库只有只读权限，工艺和车间只有查看权限、不给检出权。尤其要注意，别让所有人对所有项目文件都有"强制检入"或"删除"的权限，非标厂经常因为无意的覆盖式检入把别人的改动冲掉。权限配置一开始麻烦，但后面出问题时的追责和恢复成本会低得多。

4. 从零部署的实操记录：配置、网络和SolidWorks客户端设置

下面是我们这套环境里用下来比较顺手的配置，附上理由。具体选型按预算和供货渠道来，但关键的取舍逻辑是一样的。

4.1 两台服务器的建议配置与理由

先看表格：

为什么B机不用太多核心？因为文件共享和归档主要考验网卡带宽、磁盘吞吐和并发IO，CPU占用率通常很低。为什么A机内存尽量大？SQL Server分到的缓存越多，PDM操作响应越快，32GB是底线，64GB也不算浪费。A机的数据盘建议单独做RAID1，不要和系统盘挤在同一个盘符，数据库数据文件和日志分开存放更稳。

4.2 网络与存储规划：千兆起步，万兆更香

20人团队的办公网络，理想布局是设计区万兆到服务器，桌面千兆到PC，中间一台支持万兆上行的交换机。如果预算没到位，可以先做双千兆链路聚合顶着。经验是：大型装配体一旦超过500MB，千兆网络下检入检出的等待感会非常明显。带宽需求可以粗算：一个800MB的装配体包，千兆理论峰值约100MB/s，实际打个六七八折，拉一次就要十几秒，20人频繁操作时排队感很强。

存储区域一开始就要分清楚：PDM归档库受PDM管理，临时交换区不纳入PDM，外购件标准库做只读区，备份区独立于归档盘之外。目录结构中途搬家非常痛苦，宁可前期多花一天设计，也不要后期迁移两礼拜。

4.3 客户端和PDM端的几个关键设置

• 本地缓存路径：PDM客户端会在工作站上开一个本地缓存目录，加快打开速度。默认在C盘，C盘紧张时很容易爆。建议放到D盘或独立SSD，空间20-50GB起步。
• 检入行为：建议设置成"打开时下载最新版本，编辑时写本地缓存，保存后手动检入"，不要开自动检入。自动检入会把改到一半的文件全存回库里，后面想对比前一个版本就乱了。
• 许可证服务自启动：许可证服务务必设为开机自启、失败后自动重启。一次半夜的自动更新重启，就能让第二天早上全组坐在电脑前干瞪眼。
• 备份任务调度：建议夜间执行，错开设计人员使用高峰。数据库备份和文件归档快照分开时间跑，别挤在同一个时段互相拖慢。

5. 实际运行半年后的避坑心得：卡顿排查、备份演练和习惯养成

方案图画得再好，落地上遇到的问题往往不在服务器本身，而在使用习惯和排查思路。这部分分享几个最深的经验。

5.1 用户说的"卡"，先分清是哪一层的问题

"打开装配体好卡"是最常见的反馈，但"卡"的背后可能是完全不同的原因。正确排查顺序是：先看单个工作站，再看网络，再看PDM服务器，最后才怀疑存储瓶颈。下面这张排查表可以直接给值班的人用：

不少团队一听到卡就换服务器配置，查了半天发现是某个工程师C盘爆满了，或者同一个超大STEP文件被反复读取。把排查顺序定下来，能省下大量换硬件的冤枉钱。

5.2 备份和归档：要能定期验证，而不是自欺欺人

备份如果不做恢复演练，就等于没备份。我们当时的规定是：每周做一次备份完整性检查，每月挑一个项目做一次恢复演练，把备份拷到测试环境里打开，确认文件能正常检入检出。硬盘不会挑你想它坏的时候才坏，非标设备的设计数据一旦丢了，客户图纸补都补不回来。

提醒：备份恢复演练不是可选动作。至少每个月做一次，确认备份文件真的能打开、能正常检入检出入库。

归档方面，PDM库可以设置每个文件的版本保留策略，只留最近N个版本，更早的版本导出到离线介质。不然库会越滚越大，数据库查询也会越来越慢。

5.3 最难管的是习惯：为什么必须强制从PDM打开文件

这是整套方案里最需要坚持的一件事。如果设计人员绕过PDM，直接从Windows资源管理器双击库里的文件来打开、编辑和保存，PDM的版本记录就会产生大量覆盖和例外文件，库里记录的状态和实际文件内容对不上。解决手段分两步：技术上加权限，普通用户在归档库路径上没有直接写权限，面对PDM缓存视图时只能通过PDM客户端操作；管理上把"从PDM打开文件"写成设计部的基本流程，新人入职先带一遍操作，别指望看一眼就会。这一步落地了，PDM方案才真正有生命力，两台服务器资源也才算真正用在刀刃上。

最后再分享一点个人体会。两台服务器带动二十个SolidWorks设计，技术难度其实不高，难的是整个团队愿不愿意改习惯。我见过不少厂买了高配服务器，最后设计人员还是靠微信互传图纸，服务器只当了个文件仓库。这套方案执行得好不好，一半靠配置，一半靠流程。想上这套系统的同行，建议先从PDM库和外购件标准库这两个小闭环入手，跑顺了再谈更多功能，别一口气上全套。