金融业三个系统架构设计及硬件选型(遵循安全稳定第一原则)
本帖最后由 yanglin2199 于 2013-02-22 10:25 编辑Ａ、Ｂ、Ｃ三个系统跑APP的有6个（A1，A2，A3，A4，B1，C1），3个数据库一起9个小型机分区，高可用配起来就是18个小型机分区。
ORACLE数据库方案
方案一：
A hacmp BC
特点：
1、一个分区搞定
2、维护简单
方案二： （不知道在生产环境是否有应用，会有些什么问题）
ABC RAC ABC
特点：
1、一个分区搞定
2、维护比单节点麻烦
3、没有节点切换时间
方案三:
A RAC A
B RAC B
C RAC C
特点：
1、三个分区业务分离、风险分离。
2、维护量增加
3、成本高
应用方案：
A1 HACMP A1 (不同网段)
A2,A3 HACMP A2,A3
A4 F5 A4
B1 F5 B1
C1 F5 C1 完全不知道lz在讲什么 what are you talking about? 三个应用A、B、C都是OLTP交易系统，系统用于城商行，规模在1000亿左右，A、B系统未来五年日交易峰值是10万笔左右,C系统在1万笔以下。
A、B、C三个系统都需要ORACLE数据库，有以上三个方案可选。 没有看明白 楼主的分析、总结能力欠缺，很难看懂，其实就是A,B,C三个大OLTP数据库库系统。个人有如下建议：
1，不要太纠结于成本和维护难易，成本、维护是和应用的价值、投入相匹配的，简单的成本、维护，是不足以支持大型金融级应用的，
而且，成熟稳定的RAC系统不见得比单机系统维护更复杂，看你的架构及部署、配合能力了，淘宝还20节点的RAC呢。
2，三个业务，你可以为了风险而单独建立三个集群系统，如你的方案2，也可以放在一个大集群系统里，如你的方案3，看你的集群架构和软硬件配置、整合能力了。
比如，方案2是6台主机，三个2节点的RAC，方案3是一个6节点的RAC。个人觉得，3个RAC比1个RAC管理起来麻烦的多，而且6节点对于应用A,B,C的扩展有效的多，可以随时根据负载进行调节 回复 6# flutter
感谢flutter的回复
关于“比如，方案2是6台主机，三个2节点的RAC，方案3是一个6节点的RAC。个人觉得，3个RAC比1个RAC管理起来麻烦的多，而且6节点对于应用A,B,C的扩展有效的多，可以随时根据负载进行调节”
这一段有些出入
方案2：是2个节点的RAC+DataGuard共3台主机（不知道是否适应于生产系统）
方案3：是3套2节点的RAC+DataGuard共7台主机
我觉得，还是业务分离方便很多，不然后面万一涉及到维护重启，那可就麻烦了，业务分离，每业务单独做rac，我觉得合理些 什么叫小型机分区？没听过这个概念 ，你的方案好像也只说了数据库服务器的架构，没说应用服务器的呢 所有东西放在一个机器上，然后往机柜里加设备的时候不小心顶到开关把所有机器都一把关掉了。
:mrgreen: :mrgreen: :mrgreen: :mrgreen: :mrgreen: :mrgreen:
页:
[1]