多站点部署架构：FMS 缓存同步、TcS 集群与跨地域容灾
当企业规模扩大、分布在不同地域时，单点部署的 Teamcenter 系统往往无法满足需求。网络延迟、单点故障、数据一致性——这些问题都需要多站点部署来解决。
本文将系统讲解 Teamcenter 多站点部署的架构设计、FMS 缓存同步机制、TcS（Teamcenter Server）集群配置，以及跨地域容灾方案。
一、多站点部署模式
1.1 部署模式对比
| 模式 | 说明 | 适用场景 | 复杂度 |
|---|
| 单站点 | 所有组件部署在同一机房 | 小型企业、单一地域 | 低 |
| 多站点主从 | 一个主站点 + 多个从站点（只读） | 跨地域分支机构 | 中 |
| 多站点对等 | 多个站点对等部署，双向同步 | 全球化企业 | 高 |
| 混合云 | 本地数据中心 + 云端 | 混合 IT 架构 | 高 |
1.2 典型架构
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| 多站点架构示例：
┌─────────────────┐ 专线/VPN ┌─────────────────┐
│ 站点 A（主） │ ◄────────────► │ 站点 B（从） │
│ │ │ │
│ ┌───────────┐ │ │ ┌───────────┐ │
│ │ TC Server │ │ │ │ TC Server │ │
│ └─────┬─────┘ │ │ └─────┬─────┘ │
│ │ │ │ │ │
│ ┌─────┴─────┐ │ │ ┌─────┴─────┐ │
│ │ FMS │ │ │ │ FMS │ │
│ └─────┬─────┘ │ │ └─────┬─────┘ │
│ │ │ │ │ │
│ ┌─────┴─────┐ │ │ ┌─────┴─────┐ │
│ │ Oracle │ │ │ │ Oracle │ │
│ │ (主库) │ │ │ │ (DataGuard)│ │
│ └───────────┘ │ │ └───────────┘ │
└─────────────────┘ └─────────────────┘
|
二、FMS 多站点部署
2.1 FMS 组件回顾
| 组件 | 全称 | 部署位置 | 说明 |
|---|
| FSC | File Server Cache | 服务器端 | 主文件存储 |
| FCC | File Client Cache | 客户端 | 本地缓存加速 |
| TCCS | TC Client Cache Service | 客户端 | 轻量缓存服务 |
| FMS | File Management Service | 服务器端 | 文件管理服务 |
2.2 FMS 缓存同步机制
1
2
3
4
5
6
7
8
9
| 文件访问流程（多站点）：
1. 客户端请求文件
2. FMS 判断文件位置
3. 检查本地 FSC 缓存
├── 命中 → 直接从本地 FSC 读取
└── 未命中 → 远程获取
├── 从主站点 FSC 拉取
└── 存入本地 FSC 缓存
4. 后续访问从本地缓存读取
|
2.3 FMS 配置
主站点 FMS 配置（fmsmaster.xml）：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
| <?xml version="1.0" encoding="UTF-8"?>
<FMSConfiguration>
<MasterServer>
<Host>site-a-fms.example.com</Host>
<Port>7101</Port>
<SSLPort>7102</Port>
</MasterServer>
<FileServer>
<FSCList>
<FSC>
<Name>FSC_A</Name>
<Host>site-a-fsc.example.com</Host>
<Port>7091</Port>
<Volume>/data/fms/fsc_a</Volume>
<MaxSize>500GB</MaxSize>
</FSC>
<FSC>
<Name>FSC_B</Name>
<Host>site-b-fsc.example.com</Host>
<Port>7091</Port>
<Volume>/data/fms/fsc_b</Volume>
<MaxSize>500GB</MaxSize>
</FSC>
</FSCList>
</FileServer>
<CachePolicy>
<MaxCacheSize>100GB</MaxCacheSize>
<CacheCleanupInterval>3600</CacheCleanupInterval>
<LRUThreshold>86400</LRUThreshold>
</CachePolicy>
</FMSConfiguration>
|
从站点 FMS 配置（fmsmaster_slave.xml）：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| <?xml version="1.0" encoding="UTF-8"?>
<FMSConfiguration>
<SlaveServer>
<MasterHost>site-a-fms.example.com</MasterHost>
<MasterPort>7101</MasterPort>
<SyncInterval>300</SyncInterval>
</SlaveServer>
<FileServer>
<FSCList>
<FSC>
<Name>FSC_Slave</Name>
<Host>site-b-fsc.example.com</Host>
<Port>7091</Port>
<Volume>/data/fms/fsc_slave</Volume>
<MaxSize>200GB</MaxSize>
<ReadOnly>true</ReadOnly>
</FSC>
</FSCList>
</FileServer>
</FMSConfiguration>
|
2.4 FMS 缓存优化
缓存策略：
| 策略 | 说明 | 适用场景 |
|---|
| LRU | 最近最少使用 | 通用场景 |
| LFU | 最不经常使用 | 热点文件多 |
| TTL | 固定时间过期 | 定期更新场景 |
缓存大小建议：
1
2
3
4
5
6
7
8
9
| 单用户 FCC 缓存：
├── 轻度用户：1-2 GB
├── 中度用户：5-10 GB
└── 重度用户：20-50 GB
服务器 FSC 缓存：
├── 小型团队：50-100 GB
├── 中型团队：200-500 GB
└── 大型企业：1-5 TB
|
三、TcS 集群配置
3.1 集群架构
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| TcS 集群架构：
┌─────────────┐
│ 负载均衡 │
│ (Nginx/ │
│ F5) │
└──────┬──────┘
│
┌──────────────┼──────────────┐
│ │ │
┌─────┴─────┐ ┌─────┴─────┐ ┌─────┴─────┐
│ TC Srv 1 │ │ TC Srv 2 │ │ TC Srv 3 │
│ (Active) │ │ (Active) │ │ (Active) │
└─────┬─────┘ └─────┬─────┘ └─────┬─────┘
│ │ │
└──────────────┼──────────────┘
│
┌──────┴──────┐
│ 共享数据库 │
│ (Oracle RAC │
│ 或 DataGuard)│
└─────────────┘
|
3.2 负载均衡配置（Nginx）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
| upstream tc_servers {
least_conn;
server 192.168.1.10:7001 weight=3;
server 192.168.1.11:7001 weight=3;
server 192.168.1.12:7001 weight=3;
}
upstream tc_awc {
ip_hash; # AWC 需要会话保持
server 192.168.1.10:7001;
server 192.168.1.11:7001;
server 192.168.1.12:7001;
}
server {
listen 443 ssl;
server_name teamcenter.example.com;
ssl_certificate /etc/nginx/ssl/tc.crt;
ssl_certificate_key /etc/nginx/ssl/tc.key;
# TC Server 代理
location /tc/ {
proxy_pass http://tc_servers/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
# AWC Web 客户端
location /awc/ {
proxy_pass http://tc_awc/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
# 健康检查
location /health {
return 200 'OK';
}
}
|
3.3 会话管理
1
2
3
4
5
6
7
8
9
10
11
12
13
| <!-- tc_context.xml -->
<Context>
<!-- 会话复制（集群模式） -->
<Manager className="com.teamcenter.session.TCManager"
distributable="true"
maxInactiveInterval="3600"/>
<!-- 共享 Session 存储（推荐） -->
<Manager className="com.teamcenter.session.RedisManager"
redisHost="redis-cluster.example.com"
redisPort="6379"
maxInactiveInterval="3600"/>
</Context>
|
四、数据库多站点部署
4.1 Oracle DataGuard
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| DataGuard 架构：
┌─────────────┐ Redo Log ┌─────────────┐
│ 主数据库 │ ────────────► │ 备数据库 │
│ (Primary) │ │ (Standby) │
│ │ │ │
│ 读写操作 │ │ 只读/热备 │
└─────────────┘ └─────────────┘
配置步骤：
1. 主库启用强制日志
ALTER DATABASE FORCE LOGGING;
2. 配置 Standby Redo Log
ALTER DATABASE ADD STANDBY LOGFILE
('/data/oradata/srl01.log') SIZE 200M;
3. 配置 DataGuard Broker
DGMGRL> CREATE CONFIGURATION 'TC_DG' AS
PRIMARY DATABASE IS 'TC_PRIM'
CONNECT IDENTIFIER IS TC_PRIM;
4. 启动同步
DGMGRL> ENABLE CONFIGURATION;
|
4.2 PostgreSQL 流复制
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
| 流复制架构：
┌─────────────┐ WAL ┌─────────────┐
│ 主库 │ ────────► │ 备库 │
│ (Primary) │ │ (Standby) │
│ │ │ │
│ 读写操作 │ │ 只读查询 │
└─────────────┘ └─────────────┘
配置步骤：
1. 主库 postgresql.conf：
wal_level = replica
max_wal_senders = 10
wal_keep_segments = 64
2. 主库 pg_hba.conf：
host replication replicator standby_ip/32 md5
3. 备库 basebackup：
pg_basebackup -h primary_host -U replicator \
-D /var/lib/postgresql/data -P
4. 备库 recovery.conf：
primary_conninfo = 'host=primary_host user=replicator'
standby_mode = 'on'
|
4.3 读写分离
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| 读写分离架构：
应用层
├── 写操作 → 主库
└── 读操作 → 备库
Teamcenter 配置：
├── 事务性操作（保存、更新、删除）→ 主库
├── 查询操作（搜索、浏览、报表）→ 备库
└── FMS 元数据查询 → 就近站点
实现方式：
1. 使用 Oracle RAC 的 Service 区分
2. 使用 PostgreSQL 的 hot_standby
3. 使用中间件（如 MyCat、ProxySQL）
|
五、跨地域容灾
5.1 容灾等级
| 等级 | RPO | RTO | 说明 | 成本 |
|---|
| 冷备 | 24h+ | 天级 | 定期备份到异地 | 低 |
| 温备 | 1-4h | 小时级 | 异步复制 | 中 |
| 热备 | < 15min | 分钟级 | 同步/半同步复制 | 高 |
| 双活 | 0 | 秒级 | 双向同步，自动切换 | 很高 |
5.2 备份策略
1
2
3
4
5
6
7
8
9
10
11
12
13
| 备份策略：
├── 全量备份：每周一次（周末凌晨）
├── 增量备份：每天一次（凌晨 2 点）
├── 日志备份：每 15 分钟
└── FMS 文件备份：
├── 实时同步（热数据）
└── 每日增量（冷数据）
备份保留策略：
├── 日备份：保留 7 天
├── 周备份：保留 4 周
├── 月备份：保留 12 个月
└── 年备份：永久保留
|
5.3 故障切换流程
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| 故障切换（Failover）流程：
1. 检测故障
├── 心跳检测失败
├── 健康检查异常
└── 自动/手动触发切换
2. 切换到备站点
├── 数据库提升为主库
├── 应用服务器切换
└── DNS/负载均衡更新
3. 验证服务
├── 基本功能测试
├── 数据一致性检查
└── 通知用户
4. 原主站点恢复后
├── 同步数据
├── 降级为备站点
└── 重新建立同步
|
5.4 容灾演练
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| 定期容灾演练计划：
├── 季度演练：切换备站点，验证基本功能
├── 半年演练：完整切换流程，包含数据验证
└── 年度演练：全链路演练，模拟极端场景
演练检查清单：
□ 数据库切换成功
□ 应用服务正常启动
□ 用户可正常登录
□ 核心业务流程正常
□ 数据完整性验证通过
□ FMS 文件可正常访问
□ 通知机制正常触发
□ 切换时间在 SLA 范围内
|
六、网络优化
6.1 专线配置
1
2
3
4
5
| 专线建议：
├── 带宽：≥ 100 Mbps（建议 1 Gbps）
├── 延迟：< 50 ms（同区域），< 200 ms（跨区域）
├── 丢包率：< 0.1%
└── 冗余：双专线 + 自动切换
|
6.2 压缩与加速
1
2
3
4
5
6
7
8
9
10
11
| 数据传输优化：
├── 启用 HTTPS 压缩（gzip/brotli）
├── FMS 启用压缩传输
├── 大文件分片传输
└── 静态资源 CDN 缓存
Nginx 压缩配置：
gzip on;
gzip_types text/plain application/json application/xml;
gzip_min_length 1000;
gzip_comp_level 6;
|
七、监控与告警
7.1 多站点监控
1
2
3
4
5
6
7
| 监控维度：
├── 站点状态（在线/离线）
├── 同步延迟（DataGuard/流复制）
├── FMS 缓存命中率
├── 网络延迟与带宽
├── 各站点用户数
└── 故障切换状态
|
7.2 告警规则
| 告警项 | 阈值 | 级别 |
|---|
| 站点离线 | 3 次心跳失败 | 紧急 |
| 同步延迟 | > 5 分钟 | 警告 |
| FMS 缓存命中率 | < 80% | 警告 |
| 网络延迟 | > 100ms | 警告 |
| 磁盘使用率 | > 85% | 警告 |
| 数据库连接数 | > 90% | 紧急 |
八、总结
多站点部署是企业级 Teamcenter 系统的必由之路。关键要点：
- 架构设计：根据业务需求选择合适的部署模式
- FMS 缓存：合理配置缓存策略，减少跨站点传输
- 集群配置：负载均衡 + 会话管理 + 健康检查
- 数据库：DataGuard/流复制实现高可用
- 容灾：定期演练，确保故障切换可靠
- 监控：全链路监控，快速发现问题
多站点部署的复杂度随站点数量指数增长，建议从小规模开始，逐步扩展，每一步都做好充分测试和验证。