！！rac的节点数实际中最多可以多少？！

flyhu

大家能说说，大家在实际工作中碰到的实际应用的节点数最多的是多少呢?

另外，能介绍一下如何应用的吗？！我们现在的4节点的，都感觉后台数据库没有拉起来。

Yong Huang

原帖由 flyhu 于 2008-10-24 07:18 发表
感觉后台数据库没有拉起来。

What does that mean?

We have an 8-node RAC. It works well. Applications are are slightly partitioned among the nodes; for example, apps A, B, C run on nodes 1,2,3,4, and D,E,F on 5,6,7. Node 8 is dedicated to monitoring and RMAN backup.

Yong Huang

Yong Huang

原帖由 jf2008 于 2008-10-23 23:55 发表
几年前在东京Oracle展会上看到过128节点的，没记错的话好像是伊藤忠或者是UNISYS弄的。
主要还是炒作吧，当时和他们技术担当聊过几句，他们自己也承认节点多了节点间的通信同步是大问题。
当时好像问过他们多少个节点合适，我记得那个担当说他们测试的结果好像是别8个。
不过好几年前了，现在可能会进步些。

> 节点多了节点间的通信同步是大问题"?

Do you have the details? What is the 大问题?

> 测试的结果好像是别8个

You mean their test shows that 8 is optimal?

Yong Huang

jf2008

原帖由 Yong Huang 于 2008-10-25 04:58 发表


> 节点多了节点间的通信同步是大问题"?

Do you have the details? What is the 大问题?

> 测试的结果好像是别8个

You mean their test shows that 8 is optimal?

Yong Huang

当时我记他们show的版本是9i吧，他们在宣传的时候口气很大。后来我们问他如果把我们的OLTP应用直接移植应用到你这个128节点的服务器上，
不做什么应用修正，128节点之间的Cache fusion会不会成为瓶颈。我们当时的系统是Call Center营业方面的，法人顾客1000万，个人顾客1亿。
当时几台大服务器的在线user数都在500-1000人左右，并发更新量还是比较大的。当时展会的技术人员说128节点在Cache Fusion上可能成为瓶颈，
感觉他们没什么自信。另外他们还强调说做这个Show只是展示一下RAC的多节点，实际应用中用处不大。
后来我问他们那多少节点的比较好，我记得他说是8个，要不就12个，n年前的事情了，都是展会上逗闷子的，估计他也是随便一说吧，呵呵。

我觉得几个节点的问题还是要根据自己的应用吧，像我们现在用的RAC就是2节点，4节点的为主，没修改应用还是不敢上用户数，一直准备改应用，
通过应用控制按事业部为单位把营业员和要可能要访问的顾客数据都固定到同一节点上，尽量减少节点间的Cache交换和同步，另外当初应用上为了控制对
顾客的排他访问，用了更新LOCK,这些东西不解决，上了RAC也解决不了大问题，还不如原来用几台单机小服务器节约成本。如果不Tuning应用发挥RAC的特性，
单说增加节点，个人感觉意义不大。但现在岁数大了，对干活提不起热情了，见笑。

[ 本帖最后由 jf2008 于 2008-10-25 22:49 编辑 ]

flyhu

原帖由 Yong Huang 于 2008-10-25 04:28 发表


What does that mean?

We have an 8-node RAC. It works well. Applications are are slightly partitioned among the nodes; for example, apps A, B, C run on nodes 1,2,3,4, and D,E,F on 5,6,7. Node 8 is dedicated to monitoring and RMAN backup.

Yong Huang

一、我们的应用服务器，是通过tns里配置负载均衡模式来连接后台数据库（4节点rac）的，当时碰到如下两个问题：
1、用sqlplus或客户端连接数据库的时候，经常发生联不到后台数据库的情况，有时报0ra-12170错误，基本是3，4次有一次联不上。
2、我们前端应用是多进程并发的守护进程，一共是20个进程在同时在跑，但监控发现后台4节点数据库cpu,内存，io并没有都拉起来，并且进程分布不是很均匀。


二、您说的应用方式，是8节点的rac共享一个实例？！之后在应用端通过tns还是应用本身来使应用分布到不同的节点上？！！

三、我现在考虑我们的12节点数据库有如下几种应用方式，请大家看看那个好些。
1、12节点做一个rac，共享一个实例，在应用服务器上通过tns负载均衡方式来连接，应用程序部分不做任何的修改。
2、12节点做一个rac，共享一个实例，但使其分成3组，每组4个节点，修改应用程序和tns，来实现对不同组的连接。
3、12节点做成三个rac ,每个rac一个实例，修改应用程序和tns，来实现对不同组的连接。

不知道，那种方式更好些，更能发挥数据库服务器的作用，并且使应用修改最小，能对应用透明。
另外，各位大侠，看看还有没有其他好的应用方式。

补充，我们的数据库大概在15T左右（3年）。

[ 本帖最后由 flyhu 于 2008-10-26 08:09 编辑 ]

stableman

我建议楼主用11.1.0.7  Linux平台来做RAC， 这是一个非常稳定版本（可能先前9.1.xxx  10.1.xxx是不稳定版本给太多的人造成了xx.1.xxx就是不稳定版本的错觉）

如果希望自动均衡，只需要打开WRT这项功能(11.1.0.6/7),  RAC DB能够根据每个节点的负载情况自动将负载均匀分布于各个节点

12个节点，建议用11个VD，两个OCR，private network的网络最好能用上1G, 建一个数据库就okay了，不需要太复杂

目前，RAC在理论上支持256个节点，在日本的实验室有一个128个节点的集群

lxhde

12rac节点肯定没问题啦！

不过12个节点效率不会好到哪里去吧？之间的通讯估计是瓶颈。

stableman

所以我建议用 11个VD, 千兆private 网卡，  12个节点的通信不会成文拼劲  主要是VD的速度要快

[ 本帖最后由 stableman 于 2008-10-26 10:31 编辑 ]

Yong Huang

原帖由 flyhu 于 2008-10-25 18:04 发表
一、我们的应用服务器，是通过tns里配置负载均衡模式来连接后台数据库（4节点rac）的，当时碰到如下两个问题：
1、用sqlplus或客户端连接数据库的时候，经常发生联不到后台数据库的情况，有时报0ra-12170错误，基本是3，4次有一次联不上。
2、我们前端应用是多进程并发的守护进程，一共是20个进程在同时在跑，但监控发现后台4节点数据库cpu,内存，io并没有都拉起来，并且进程分布不是很均匀。

二、您说的应用方式，是8节点的rac共享一个实例？！之后在应用端通过tns还是应用本身来使应用分布到不同的节点上？！！

Why don't you use server side loading balance (create a service and modify it with dbms_service)? I think Oracle recommends that over client side load balance.

I don't know why you got ORA-12170. Did you get any other errors in alert.log, udump, or listener log? Did you try SQL*Net trace to see if there's any clue?

By "cpu,内存，io并没有都拉起来", you mean those numbers stay low, i.e., those resources are not fully utilized. Correct? Server side load balance is controlled by the listeners, which have the latest node CPU usage (periodically updated from each node's PMON), so server side load balance may solve your uneven distribution problem.

"8节点的rac共享一个实例"? I don't understand. We have an 8-node RAC, each node running one instance. All access the same database. "实例" in Chinese means instance, not database.

Yong Huang

Neverwinter_New

[quote]原帖由 jf2008 于 2008-10-24 13:55 发表
节点多了节点间的通信同步是大问题。
当时好像问过他们多少个节点合适，我记得那个担当说他们测试的结果好像是别8个。
。


节点之间的同步确实是个问题.其中CACHE FUSION 是瓶颈所在.同意楼上观点.
8-12个 NODES应该是最优的平衡点.

对CACHE FUSION技术不是很熟悉,所以查了一些资料.
"Oracle RAC Cache Fusion uses a high-speed IPC interconnect to provide cache-to-cache transfers of data blocks between instances in a cluster."
这里的"high-speed IPC interconnect"中的high-speed 到底可以达到多大??请高人解答??

THANKS