AWC2406 Deployment Center部署配置与故障排查指南

简介这份文档面向Teamcenter实施与运维人员聚焦使用Deployment Center部署AWC2406的完整流程适合正在搭建测试环境、核对安装配置或排查部署问题的中级读者参考。压缩包内为1个docx文件约4.67MB以图文笔记形式组织安装准备、环境配置与组件部署等章节便于按目录快速查阅。已有312人学习下载在同类部署资料中具有一定参考价值。内容涵盖安装前的主机名调整、防火墙关闭与IPv6禁用JDK17.0.3、Siemens License Server和SQL Server2019的安装要点以及将AWC2406介质加入Deployment Center存储库时的路径与日志排错提示。环境与组件部分涉及环境创建、可用软件更新、应用程序选择以及Active Workspace Client、Gateway、Corporate Server、Database Server等组件的顺序配置并提示Database Server与TC密码的特殊字符限制。文末还说明生成安装脚本、定位deploy_XXX.zip并运行deploy.bat的部署方式可帮助读者对照检查配置、减少重复试错适合作为官方文档之外的实操型补充材料。1. 从一台干净的 Linux 说起AWC2406 部署到底难在哪手上拿到一台刚装好的 Linux、一份 AWC2406 介质、一个 Deployment Center 压缩包任务是把这套 Web 客户端跑起来。第一次接触的人多半会卡在 Deployment Center 的表单页选项太多看起来每项都能填填错一项后面全盘报错。AWC2406 是这套 PLM 平台的 Web 客户端Deployment Center 是配套的图形化部署工具它把“装哪些组件、装在哪个目录、连哪个库、开哪些端口”收敛成一套模板变量。适合照着做的是实施和运维工程师不用先啃完手册但得知道自己在填什么。反直觉的是真正让人翻车的不是点按钮而是点按钮之前那几项环境基线包括主机名、Java 版本、库连通性、卷权限任何一项没对齐最后都会收到一句语焉不详的失败提示。2. Deployment Center 的模板机制为什么它决定了后面所有的坑装过两三次之后会发现Deployment Center 界面上点的每一步落到磁盘上就是同一份部署包。理解这一层排查效率会差出一个数量级界面报错只是表象真正的线索在模板变量和渲染出来的配置文件里。这一章先把机制讲透后面配置参数和排查故障才有判断依据。2.1 Deployment Center 的真实产物是一份 TEM 部署包Deployment Center 本身不装任何东西它是模板的渲染器。模板里包含四类内容组件定义说明这套部署有几个组件、每个组件对应哪个安装包变量定义包括主机名、端口、数据库连接这类的占位符依赖顺序规定谁先启动、谁依赖谁执行脚本包括解压、配置替换、服务注册这一串动作。你在界面上填的每一个值最后都被替换进模板的占位符生成一份可执行的部署包。这个理解带来的第一个判断是部署失败先查变量渲染再查环境。界面上的红色提示往往只是“某个步骤退出码非零”真正的原因藏在部署包目录的配置文件和日志里。我一般会先执行一遍占位符检查看有没有${这种没被替换掉的东西残留。# 进入 Deployment Center 生成的部署包目录 cd /opt/awc2406/tem/awc2406-deploy # 检查配置文件里是否还有没被替换的占位符 grep -rn \${ ./config/ ./scripts/ || echo 占位符已全部替换逻辑很直接模板变量只要有一个没赋值渲染结果里就会留下${xxx}原样。这种配置在启动阶段通常不会立刻报错等到服务去连数据库或者注册到网关时才炸报错信息还跟根因隔了好几层。grep的退出码非零就代表没找到||后面那行是给正常情况一个明确回显免得你盯着空输出怀疑命令没跑。第二个判断是不要在原始模板上直接改。介质自带的模板是只读的一部分升级或者重新解压介质时会被覆盖你之前调过的参数全丢。常见做法是导入模板后立刻克隆一份命名带上环境和日期后续所有修改都在克隆体上做。多人共用一个模板更麻烦A 改了端口B 重新渲染一次就把 A 的改动冲掉排查时互相怀疑这种血泪经验在实施现场一点都不少见。第三个判断是版本匹配。模板版本必须和 AWC2406 介质版本对应错配的典型表现是变量名对不上你在界面里填的“网关端口”渲染出来根本没落到配置文件里因为新模板里这个变量已经改名了。Deployment Center 的界面不会拦这种错它只认变量名不认你的意图。拿到介质先确认模板来源别从别的项目目录随手拷一份过来用。2.2 AWC2406 的三层拓扑Web 接入、微服务与数据层AWC2406 不是一个单体应用它至少分三层。分清这三层端口规划、日志定位、启动顺序才有依据。层级主要组件职责常见故障表现Web 接入层Servlet 容器 AWC 应用包接收浏览器请求转发给网关页面 404、静态资源加载失败微服务层网关、注册中心、若干业务微服务路由、鉴权、业务逻辑页面能开但接口 502登录后空白数据层数据服务端、关系型数据库、FSC、卷持久化、文件存取登录报错、附件上传卡住部署顺序上数据层必须先就绪。数据库能连、FSC 端口通、卷目录可写这三件事没做完就往下走微服务启动时会一直重试连接日志刷得飞快但看不出重点。微服务层起来之后才是 Web 接入层因为 Web 层启动时要向注册中心报到注册中心没人容器起得来但页面打不开。端口规划要按层来做。网关独占一个对外的端口微服务实例从一个连续端口段里分配Servlet 容器自己再占一个。规划时把这几个区间一次划好别和机器上已有的服务打架。我一般会在环境检查阶段就把整个端口段扫一遍而不是等部署到一半报 bind 异常再回头改。日志也是分层的。每层日志目录不同排查时先定位是哪一层的问题再进对应目录比在一个大日志文件里翻要快得多。这一条听起来废话但在现场把 Web 层日志当成全部日志看是最常见的误判来源。2.3 部署前先过一遍这张环境基线表Deployment Center 的表单再长也覆盖不了环境本身的问题。下面这几项必须在打开浏览器之前确认完否则后面每一步都在赌。检查项要求怎么查操作系统版本在介质支持列表内cat /etc/os-releaseJava 版本与 AWC2406 要求的主版本一致java -version主机名解析本机能用主机名解析到自己getent hosts 主机名端口模板要用的端口全部空闲ss -lnt逐个核对磁盘安装目录和日志目录分开留足余量df -h时钟与统一时间源同步timedatectl库连通端口通且账号能实际登录客户端执行一条查询卷权限应用账号可写不是 root 可写用应用账号 touch 测试这张表里最容易被跳过的是主机名解析和时钟。主机名只在部署后改一次服务注册信息、证书里的名称全对不上恢复起来比重装还费劲。时钟偏差不用太大微服务之间校验令牌就会失败表现出来的现象是“登录成功但立刻被踢回登录页”很容易被当成账号问题去查。3. 部署前的四道环境检查主机、Java、数据库与共享卷环境检查这一步没有 Deployment Center 界面那么有存在感但它决定了后面所有步骤是顺水推舟还是反复返工。这一章按四道检查展开每道给可直接执行的命令跑完再开部署。3.1 主机名、专用账号与目录规划主机名要一次定死。服务注册、证书、配置文件里都可能引用它部署完再改等于把一堆注册信息变成脏数据。同时要保证本机能用这个主机名解析到自己很多启动脚本第一步就是拿主机名做自检。# 固定主机名并确保本机能用主机名解析到自己 hostnamectl set-hostname awc2406-node01 grep -q awc2406-node01 /etc/hosts || echo 10.20.30.41 awc2406-node01 /etc/hosts getent hosts awc2406-node01 # 建专用账号应用不要用 root 跑 useradd -m -s /bin/bash awcdeploy mkdir -p /opt/awc2406/{app,logs,temp,data} chown -R awcdeploy:awcdeploy /opt/awc2406 chmod 750 /opt/awc2406 # 安装目录和日志目录的磁盘余量要分开看 df -h /opt /var /tmpgetent hosts是验证解析最直接的方式它走的是系统解析链路和启动脚本看到的结果一致。专用账号的意义不只是安全文件属主错了服务写日志会失败而这类失败经常被包装成“日志组件初始化异常”让人往错误方向查。目录分成 app、logs、temp、data 四个是为了后面排查时能按类型定位临时文件被系统清理导致启动失败这种坑把 temp 放到/tmp下就会遇到。chmod 750是防止同机其他账号误读配置里的口令。3.2 Java 与系统参数的检查命令Java 版本不对Deployment Center 有可能照样把包生成出来直到服务启动才报UnsupportedClassVersionError。所以版本检查要放在最前面而且要检查运行部署的那个账号下的 Java不是 root 下的。# 用应用账号检查 Java别用 root 的 su - awcdeploy -c java -version su - awcdeploy -c echo $JAVA_HOME # 文件句柄与进程数上限微服务数量多时默认值不够 ulimit -n ulimit -u # 端口占用预检把模板里打算用的端口先排一遍 for p in 8080 8443 9001 9010; do if ss -lnt | awk {print $4} | grep -q :$p$; then echo 端口 $p 已被占用 else echo 端口 $p 空闲 fi done # 时钟同步状态 timedatectl | grep -E System clock|synchronizedulimit -n默认值常见是 1024AWC2406 这一套微服务加上连接池很容易顶到这个上限表现是运行一段时间后开始报“too many open files”重启就好、过一阵又犯特别像玄学。修的时候别只改当前会话写进/etc/security/limits.conf并且确认服务是通过登录会话启动的否则不生效。端口预检的脚本里ss -lnt输出第四列是本地地址加端口用awk取出来再匹配比grep :$p精确避免 8080 匹配到 18080 这种误判。时钟那一行看的是System clock synchronized是否为 yes不是看时区对不对这两件事经常被混为一谈。3.3 数据库连通性与文件卷权限预检数据库这块端口通只是第一层。防火墙放行、账号没锁、库字符集支持中文这三件事任何一件不满足都会在登录或者建表阶段炸出来。# 第一层端口连通性 nc -zv db-host 1521 # 第二层用真实账号实际登录一次别只看端口 # 以下为通用客户端示意换成你们环境里的客户端 dbclient -h db-host -p 1521 -U awc_user -d awcdb -c select 1 # FSC 端口连通性 nc -zv fsc-host 9000 # 卷目录权限用应用账号测不是 root ls -ld /data/volume01 su - awcdeploy -c touch /data/volume01/.wtest rm -f /data/volume01/.wtest echo OKnc -zv只证明网络层通证明不了账号可用。实际登录一次的意义在于把口令错误、账号锁定、库不存在这几种情况提前暴露而不是等部署到一半连接池初始化失败。卷权限用应用账号测是关键root 能写不代表应用能写而附件上传失败的现象往往是“上传进度卡在 99%”日志里只有一句权限异常不点进去看不出是哪个目录。文件卷还有一项容易漏共享卷如果是网络挂载要确认挂载参数里没有限制文件大小或者禁止某些操作否则大附件写一半失败重试也一样失败。4. 用 Deployment Center 生成 AWC2406 部署包六组参数怎么填环境过了才轮到 Deployment Center 出场。这一章按实际操作顺序走导入模板、克隆、填参数、生成、试运行。参数部分按六组归类每组说清楚填错的典型症状。4.1 导入模板并克隆一份自己的打开 Deployment Center 之后第一件事不是新建是导入介质里自带的模板。导入完先别动直接克隆一份命名规则建议带上环境和日期比如awc2406-prod-202406。克隆的好处是原始模板保持干净升级或者重新导入时不会把历史修改带进来。克隆之后先看模板的组件树确认里面包含的组件和你要装的层次一致。如果数据服务端已经就绪模板里应该只有 Web 层和微服务层如果是从零开始模板会把数据层也带上这时候参数会多出一大截别漏填。组件树里每个节点都能展开看变量列表填之前先扫一眼有没有明显标红的必填项比填到一半被打断要好。还有一点模板里的默认值不要照单全收。默认端口、默认路径在演示环境能用在生产环境十有八九冲突。我的习惯是把所有默认值过一遍凡是涉及端口和路径的全部改成规划好的值改完再统一检查一遍。4.2 六组参数逐项填主机、端口、数据库、管理员、FSC、证书参数表按组看比在界面上一个个找要清楚。下面这张表里的“填错的表现”是实际排查时最省时间的线索。参数组典型项填错的表现主机与路径部署主机、安装根目录、临时目录、日志目录服务启动找不到配置或日志写不进去端口网关端口、微服务端口段、容器端口启动报 bind 异常或页面完全打不开数据库主机、端口、库名、账号口令、连接池上限启动时连接池初始化失败登录报 SQL 异常管理员初始管理员账号、口令、所属组织页面能打开但登录 401/403FSC 与卷FSC 主机端口、卷名、共享路径附件上传卡住或上传成功但下载 404证书与 SSO证书路径、别名、SSO 开关与跳转地址页面证书告警或登录跳转死循环主机与路径这一组重点在“应用账号要有写权限”。Deployment Center 生成部署包的时候用的是当前登录账号执行部署的可能是应用账号两者不一致时最常见的现象是部署进行到一半报“无法写入”但目录ls出来权限看着是对的。临时目录单独规划别用系统默认的/tmp那个目录有清理策略服务跑一段时间后临时文件被清掉报错信息通常和真实原因无关。端口这一组微服务端口段要连续。不连续也能配但后面扩节点、加实例的时候会很难受。端口填完回看一眼有没有和 3.2 里扫出来的占用冲突这个顺序别反。数据库这一组连接池上限不要照抄模板默认值。并发量小的环境默认值够用并发一上来连接不够表现是间歇性超时很难复现。库名和账号要区分大小写某些库在特定配置下大小写不敏感换一台机器就敏感了这种问题在迁移时特别常见。管理员这一组初始口令要符合口令策略否则部署脚本创建账号那一步静默失败后面登录一直报认证错误你以为是服务没起来其实服务好好的。FSC 与卷这一组卷名和路径必须和实际挂载的一致。卷名对不上服务启动不报错上传附件时才失败。证书与 SSO 这一组如果暂时不上 SSO开关一定要显式关掉别留空。留空的行为在不同版本里不一致有的当成关闭有的当成开启然后去连一个不存在的地址表现就是登录页一直转圈。4.3 生成部署包、试运行、正式执行参数填完点生成。生成之后先别急着执行做两件事占位符自检和试运行。这两步加起来不到五分钟能省掉一次失败重来。cd /opt/awc2406/tem/awc2406-deploy # 自检确认没有未替换的占位符 grep -rn \${ ./config/ || echo 没有未替换的占位符 # 试运行只打印将要执行的动作不落盘 ./tem.sh -t deploy --dry-run # 正式执行输出留档 ./tem.sh -t deploy 21 | tee /opt/awc2406/logs/deploy-$(date %Y%m%d%H%M).log第一行grep的退出码非零表示没有匹配也就是干净。如果匹配到了输出里会带文件名和行号直接定位到是哪个变量没赋值。--dry-run这个参数在不同版本的部署脚本里名字可能不同有的叫-n有的叫preview以你拿到的部署包里tem.sh --help的输出为准。试运行的价值在于看执行顺序数据层是不是排在微服务层前面Web 层是不是最后顺序错了说明模板选错了这时候改还来得及。正式执行用tee留一份带时间戳的日志这个习惯在出问题的时候价值极高。部署失败的现场往往会被下一次重试覆盖有日志就能回看第一步到底报了什么。日志文件名带时间戳多次重试不会互相覆盖。执行完之后不要只看最后一行是不是成功。逐段翻一下输出特别是中间那些被标成 warning 的行很多问题在部署阶段只是 warning运行一段时间才变成故障。5. 部署失败排查AWC2406 安装的 5 个高频翻车点部署失败的表现千奇百怪但根因收敛下来就那么几类。这一章按“现象、原因、解决”的方式列五条每条都是我在现场真实遇到过不止一次的。5.1 服务进程起来了但页面打不开现象ps -ef能看到进程端口也在监听浏览器访问一直转圈或者直接连接被拒。原因通常有三种。第一种是 Web 接入层起来了但微服务层没起来Web 层只是个转发壳子后端没有注册中心可用请求发出去没人接。第二种是防火墙只放行了本机外部访问被挡本机curl能通换台机器就不行。第三种是证书问题浏览器对自签证书的处理策略不同有的直接拒绝页面看起来就是打不开。解决顺序是先用本机curl打网关的健康检查地址返回码正常说明服务本身没问题问题在网络或证书返回码异常就进网关日志看注册情况。注册中心里如果只有网关没有业务微服务回到微服务日志找启动失败的原因通常是数据库连接或者端口冲突。5.2 登录报错先分清是认证还是授权现象页面能打开输入账号口令之后报错有的提示认证失败有的提示无权限还有的登录成功但立刻跳回登录页。原因分三类。认证失败多半是初始管理员没创建成功或者口令不符合策略被脚本跳过了。无权限是账号建了但没分配组织或者角色属于配置遗漏。登录成功立刻跳回八成是时钟偏差导致令牌校验失败或者 SSO 开关状态和实际配置不一致。解决时先看认证服务的日志别在 Web 层日志里找。认证日志里会明确写是“用户不存在”“口令错误”还是“令牌过期”。令牌过期这一类先去核对 3.2 里的时钟同步再回头看 SSO 配置。这个顺序能省掉大量无效排查。5.3 附件上传卡住多半在 FSC 和卷权限现象上传小文件正常大文件卡在某个百分比不动或者上传成功但下载报 404。原因FSC 服务没起来或者卷路径配置和实际挂载不一致。还有一种情况是共享卷的挂载参数限制了单文件大小超过阈值的写入直接失败。解决先确认 FSC 端口通、进程在再看应用账号对卷目录有没有写权限。这两步在 3.3 已经做过一遍但部署之后目录属主可能被部署脚本改掉需要复查。大文件失败的话看挂载参数里有没有文件大小限制有就调整或者换存储路径。5.4 端口冲突与重复部署的清理现象第二次部署时报端口被占用或者服务起两个实例互相抢注册。原因上一次部署失败之后没清理干净进程还在端口还占着。或者部署脚本把服务注册成了系统服务重装时旧服务没卸载。解决部署前先ss -lnt扫一遍发现有残留进程就按端口找到 PID 再处理。系统服务用对应的管理命令确认状态别直接删文件删了注册信息还在下次启动照样拉起一个残缺实例。重装之前养成习惯停服务、确认端口释放、再执行部署。5.5 时间不同步引发的令牌失效现象登录成功点任何一个菜单都提示会话失效反复登录反复失效。原因微服务之间校验令牌时会比对签发时间和当前时间偏差超过阈值就判定失效。容器化部署时宿主机时间正常但容器内时间漂移也会出现同样的现象。解决先看宿主机timedatectl的同步状态再看容器内时间和宿主机是否一致。同步服务配置好之后重启相关微服务让它们重新取时间。这一条特别隐蔽因为所有日志看起来都正常只有令牌校验那一行是 warning。6. 部署后的验证与增量重部署三条命令和一次最小化重跑部署脚本返回成功不等于系统可用这一步要自己验证。验证分两层服务活着和业务能走通。6.1 三条命令确认服务真的活着# 1. 进程在不在 ps -ef | grep -i awc | grep -v grep | wc -l # 2. 端口在不在监听 ss -lnt | grep -E :(8080|8443)\b # 3. 网关健康检查看返回码 curl -k -s -o /dev/null -w %{http_code}\n https://awc2406-node01:8443/ # 4. 日志里最近的错误 tail -n 300 /opt/awc2406/logs/gateway.log | grep -iE error|exception | tail -n 20第一条数进程数量和预期组件数对不上就说明有服务没起来。第二条看端口\b是为了避免 8080 匹配到 18080。第三条只看返回码200 或者 302 都算正常5xx 就要进日志。第四条是补充日志尾部有 ERROR 不一定代表当前有问题但连续出现同一条就值得看。这四条跑完只能说明服务层活着。业务层还要走一遍登录、打开一个模块、上传一个附件、下载回来。这四步覆盖了认证、微服务路由、FSC 和卷基本能暴露大部分配置问题。6.2 改一个参数后的最小化重部署部署完发现某个参数填错了最忌讳的是全量重装。全量重装耗时不说还会把已经配好的数据覆盖掉。判断标准很简单改的东西影响不影响已经写入的数据。改动类型是否需要全量重部署说明日志级别、超时时间否改配置文件后重启对应服务端口、主机名否改配置后重启注意注册信息要刷新数据库连接否改配置后重启连接池会重建组件增减是组件树变了必须重新渲染部署包版本升级是介质变了走升级流程不是重装判断完之后非全量的改动走“改配置、重启、验证”三步别碰部署包。全量的改动才回到 Deployment Center 重新渲染。我一般会在改之前把原始配置文件备份一份改完对比一下确认只动了预期的那几行。最后说个自己的习惯。每次部署完成我会把这次用的模板名、关键参数、部署日志、验证结果记在一个文本文件里放在部署目录旁边。下一次遇到同样的问题翻这个文件比翻聊天记录快得多。这套东西的很多坑不是技术难题是信息丢失谁在什么时候改了什么过两周就没人记得。把它记下来比任何排查技巧都管用。希望帮到你。本文还有配套的精品资源点击获取