有奖讨论：DB2多分区系统如何决定分区数量

wolfop

我笨故我在 发表于 2012-4-18 09:53
X86挂本地磁盘的集群，个人感觉才是体现出了DPF的价值。性能强价格低
我这里就用X86加本地磁盘做的集群代 ...

内置盘？你用什么方法解决单节点DOWN机的情况？gp是靠segment 的复制，DB2没有这种功能吧？

我笨故我在

wolfop 发表于 2012-4-18 21:20
内置盘？你用什么方法解决单节点DOWN机的情况？gp是靠segment 的复制，DB2没有这种功能吧？

DPF本身没有考虑高可用目前看确实有些落伍，不像gp和mysql NDB cluster本身就可以实现高可用。
一般情况下DPF的高可用要靠机器的HA来实现，我们如果用PC server+内置盘可以用DRBD+heartbeat的方式来实现
不过传统的HA存在设备闲置不能充分利用，接管等问题比较让人讨厌。
如果换一种解决思路可能会更简单：部署两套（或两+）集群，前端用负载均衡。
关于数据一致性问题，集群外需要ETL导入的数据首先导出到文件，再分别导入到两个集群。这样两个集群的原始数据是一样的，上面部署相同的批量任务，那么加工出来的数据也是一样的。每天监控看看两边是不是跑批都成功，这样就能保证两边的数据都一致。
注意两点就可以：
1 外部导入的数据，需要两边都导入
2 批量任务两边都相同，并确认都成功
当然具体到不同环境需要考虑的东西有多少之分
这样的好处很明显设备没有闲置，两倍的性能，0切换时间，容灾更容易

wolfop

我笨故我在 发表于 2012-4-19 10:11
DPF本身没有考虑高可用目前看确实有些落伍，不像gp和mysql NDB cluster本身就可以实现高可用。
一般情况 ...

DRDB啊？冷备份节点？10GE？
双EDW这种做法，呵呵我不认为是好方式。本来DW应用日常的大量工作就是对数，两个库，维护两套应用累死应用维护人员。最后这种方法也就适应在发达国家应用需求极端固定的情况。国内的情况就是最后两边自己都对不上。而且双EDW可不是双倍性能，和1+1冷倍一样是计算和存储能力的浪费。

我笨故我在

wolfop 发表于 2012-4-19 13:46
DRDB啊？冷备份节点？10GE？
双EDW这种做法，呵呵我不认为是好方式。本来DW应用日常的大量工作就是对数， ...

双集群如果对性能都没帮助和1+1冷倍一样是计算和存储能力的浪费，那我真没什么好说的了。你直接无视吧
双集群提升的是用户体验，对内部数据的加工没帮助，使用闲置设备并提供HA。
在传统的DB2客户里，如果是甲方的运维人员是不会绝不会自己主动去搞任何哪怕增加一点麻烦和风险的东西的，如果有乙方提供服务则另当别论了，这是责任谁抗的原则性问题如果是我我也一样
而且如果某甲方有个需求，马上会有一堆厂商和公司盯上这块肥肉，PC server方案？乙方们肯定连考虑都不带考虑的，利润太低。不说其他的PC server的方案在“大甲方”们那里一时半会儿都不会有市场
至于复杂度，这真是个永远都说不完的问题。非要完美的方案这个世界上还真不存在。就像mysql要找缺点一堆，但mysql就是在蓬勃的发展着。
扬长避短适合就好了，一定要求全责备那什么都别做了，有空喝喝茶聊聊天休息休息多好
“大甲方”们那里一套DW可能有N个服务商，要协调用统一的方式管理维护。。。算了还是硬件备份简单的多
可以做一个小的应用，通过该应用来部署job到两个集群并监控运行结果。每天打开界面看看这些job是否正常就好了。对DW里跑的任务归归类，汇总成我们认为合适的job
如果大家有空看看mysql的开源项目，看看mysqlers做的工作，再看看这个应用就不会觉得挑战性多么大了
双集群的方法在极端复杂的DW环境，维护是麻烦一些。但一般的应用我相信没什么问题，只要想做。不论别人怎么说我这里跑的是很好的
我也没期望别人也采用一样的方案，这个方法也不会被很多甲方们采用，这是肯定的。
我只是让大家看看，DB2也是可以用PC server的，也一样可以跑的很好，也是有改进变通的方法的

我笨故我在

我现在这里就简单多了，只有跑的好而且有省钱，老板就高兴
老板高兴了，我们自然也就高兴了
自然就更有动力去瞎搞了

我笨故我在

wolfop 发表于 2012-4-19 13:46
DRDB啊？冷备份节点？10GE？
双EDW这种做法，呵呵我不认为是好方式。本来DW应用日常的大量工作就是对数， ...

可能说的不是很清楚
两个集群是通过负载均衡同时对外提供服务的
因为我是双集群，集群内部就没必要用备份机器了。两个集群本身就起到互备的作用了
如果是单集群的话，才需要考虑DRBD+heartbeat
考虑双集群的最初始想法就是用HA机器备份太浪费设备，并且HA的接管也麻烦。并且集群扩展或调整影响业务
双集群可以避免这些问题。维护集群可以一套先下线维护，另一套对外服务。调整完后，新的对外，另一套再下线调整，对业务没有影响
如果单集群就有较好的高可用，维护简单不影响业务，那么我们也不会考虑双集群的

mdkii

我笨故我在 发表于 2012-4-18 09:53
X86挂本地磁盘的集群，个人感觉才是体现出了DPF的价值。性能强价格低
我这里就用X86加本地磁盘做的集群代 ...

这也是我认为DPF应该发展的方向，但我还没有实际搭建过。
希望你能分享更多的信息。比如什么机型，什么配置，划了了多少个分区，
多大数据量，每天处理多少数据量，什么类型的应用？
使用下来维护成本高不高？
如果您认为这些信息不方便公布，可以消息给我，非常感谢。

至于wolftop说的问题确实存在，在PC上，高可用性确实是个问题。我不知道什么是DRDB，HADR吗？
貌似DPF不支持HADR。
双加载方案其实也不是太好，我们的EDW就用了双加载方案，在ETL JOB日益增多的时候（我们这里超过了1W个）维护成本很高。另外，如果有些应用需要实时的回流一些信息到EDW，数据的同步又会变成一个很麻烦的问题。至于你说的双系统的负载均衡。其实如果在EDW的应用中，机器合起来用可能比拆开来性能更好。我觉得双加载只能适合在那些7*24小时要求而数据量又比较大的系统。在PC机的层面上的高可用性，除了数据复制外，似乎没有好办法。

使用本地硬盘似乎还有另一个问题。就是并发IO性能。我们曾经测试过GP的性能，它就是用的PC机的本地盘。在单任务的时候，性能确实还不错。但是当并发量加大时，性能几乎成线性下降。感觉PC机的内置盘的IO吞吐量还是有限的，一个原因可能是IO带宽问题，另一个可能是相对于存储来讲，本地盘没有巨大的CACHE，所以压力上来的时候，磁盘一直是 100%busy。不知道你的这个PC版DPF有没有类似的问题。

mdkii

我笨故我在 发表于 2012-4-19 17:06
双集群如果对性能都没帮助和1+1冷倍一样是计算和存储能力的浪费，那我真没什么好说的了。你直接无视吧
双 ...

甲方现在也在考虑成本的。。。
双系统除非是非常关键的应用，否则不太会考虑的。。
双系统远比你想象中投入的要多。比如，如果生产是双系统，那么很多测试环境也要双系统。。。

我笨故我在

晕倒~都双集群了还考虑什么PC的高可用
我这里就是双集群投入成本我不用想象，测试环境一般不需要双的，就是用双的还不至于增加设备的成本，环境少分点资源就是了
PC的IO能力不用怀疑，之前做乙方时见过一个客户买了3650 12*sas 用的RAID卡连cache都没有 直接晕倒~

zcl32

高可用的话，对于DPF我觉得还是利用TSA实现N+M（比如N+1，N个活动的节点，1个热备用节点）比较好，不过我们也只是在进行评估阶段，感觉这个方面有些不稳定。
对于双系统，我们遇到的最大的难题就是数据不一致的情况。前端应用把业务同时交给两套数据库进行处理，但是为了保证高可用性，又允许其中的一个数据库宕机。数据库宕机后再起来就有不一致的数据库，除非应用端对于业务数据进行本地缓存。但不管怎样，两套环境的数据即使正常情况下在某个时间点对于一个查询来说都可能存在不一致。这就要看业务对于高可用性和数据一致性的取舍了。如果数据量就是很大，分布在多个节点上，对一致性要求不高的话，基本上就成了NoSQL了。IBM原来说的是DB2中会加入nosql的特性，不过在10.1版本里面还没有看到。