回复 9# InfoCore-Great
CDP，好像这次宁夏银行的重大事故就和CDP有关吧。
本帖最后由 100心 于 2014-08-06 21:52 编辑
ls换了个新马甲？这事件众说纷纭啦，都不知道具体谁对谁错，反正遭殃的是用户的IT部门。回复 11# mike1979
回复 12# 100心
原来的号密码忘了。
从银监会的通报来看，应该是指向CDP。不过这种通报都是含糊其辞，模糊真相。
本帖最后由 100心 于 2014-08-07 09:43 编辑
但CDP厂商就说用户项目完成后就没续保了，出了事也没咨询和请教原厂人员。
忘记密码找管理员弄回来啊，老账号看着亲切。mike1979 发表于 2014-08-07 09:39 static/image/common/back.gif
回复 12# 100心
原来的号密码忘了。
从银监会的通报来看，应该是指向CDP。不过这种通报都是含糊其辞，模 ...
回复 10# 100心
Hi guys,
那张图，是我做的，很久之前。
因为是厂商，所以，同机房或者-Metro Cluster-High Availability都是基于自己家产品做的。
架构我通常会分成三层，业务层，网络层（通常是SAN），和存储层。
业务层，通常不同业务的应用主机，跨机房组建集群。
网络层，用户有条件会拉几颗光纤，或者租用（DWDM），使用iSCSI也有，不过很少，因为通常压力测试下来，延迟太高。
存储层，其实网络层就是为存储层服务的，里面跑的是实时镜像的IO。
至于CDP，各家产品不能一概而论，我是从始至终就没有靠它做容灾，仅仅是对于业务层的逻辑错误，病毒攻击，软件升级带来的bug，进行密集时间点的快速恢复。
各方面组件：应用层的集群软件-最好支持load balance,网络层的-SAN设备，交换机，适配器，DWDM（if needed），不过由运营商来做，存储层-集群模式<实时镜像>，最好支持跨机房的Active/Active,也就是存储层的双活，更好的迎合应用层的load balance；
另外，Flash /SSD近些时候我都在使用，可能很少人会发现，针对跨机房之间链路，规避延迟它有很大的帮助:wink:
回复 14# 100心
不买保，不出事就算了，出了事板子当然要打在你身上。何况7年不保，厂商只要说时间太久了，不熟悉情况，不敢轻举妄动。
不过我看了CDP的原理后就觉得不会向客户推荐这个产品。Unix平台上基于LVM镜像+快照获取生产数据，LVM镜像本来就要求两个分支的存储性能差不多。CDP还要做快照，那么配置应该比另一台存储更高才行。可实际上都是CDP的配置更低，IO瓶颈都在CDP上。
锅铁做 发表于 2014-08-07 10:44 static/image/common/back.gif
回复 10# 100心
Hi guys,
就算在同一个机房内，用SSD对规避延迟也有很大帮助。
两个机房在同一个building内，就算1km距离吧，光纤上IO来回的额外延迟0.02ms。系统和存储在同一个机房内，IO都在2ms内完成就算性能很好了（这个可以参考oracle的log file sync等待事件），那也只增加了1%的延迟。
要做测试的话，在同一个机房内，用SSD和不用SSD做两个实验，记录IO延迟。然后同一个building内，跨机房，用SSD和不用SSD做两个实验，记录IO延迟。
4个实验的数据比对下就知道了。
传说中的bj大神出现了？
现阶段，磁带是最快的备份设备。
我对cdp之流一向很讨厌