姜玉明

这个问题非常庞大，绝对需要从DAS，SAN，NAS的产生和发展来分析；简单回到两点；1,对于IO敏感的业务系统，还是需要采纳集中式的SAN架构；2,NAS存储平台，需要看是否有分析&高性能的需求，有那么就要按照高性能的思路去搞，没有就可以

任何IT需求，都有很多解决方案；就相同的对象存储，很多厂家都说有自己的解决方案，但是我想大家对于产品，方案以及对不同客户的生态环境都是不尽相同的；从和很多客户沟通的结果来看，结合企业资深的技术储备，企业自身的IT发展战略

非常好的一个问题；作为it架构中的一部分，必须考虑其故障影响，SVC是成对出现的，单个SVC节点故障，另外的节点是可以快速接管的，如果是两个都有故障了，可以另外两个节点自动接管；目前实施了svc的银行客户很多；1，人民银行，大小额，影像

建议采纳hyperswap方式；

上一套IBM specturm control软件即可；

建议网上搜一下，宁夏银行飞康宕机，去了解一下；

很多概念大家的理解不一致，但业务连续性是一个咨询的话题，一定以客户的需求为出发点； 更新一下ibm的svc技术，容灾架构，任意环节产生快照，可以写入IBM Softlayer, Openstack Swift, Amazon S3云平台；

简单回答，越底层的技术，运维越简单，越上层的技术，对运维的要求越高！

这个几个不是一个层面的东西，保护的目的也不尽相同；说一下我的理解；第一，主机级别的ha是必须要有的；第二，存储级的复制也要有的；第三，数据库级别的，也可以有； 关键是第二个和第三个，运维团队熟悉哪个用哪个，也可以都有！

同意楼上两位的说法，没有不回发生故障的设备，这里我在补充一下；第一，SVC节点故障，另外一个节点可以接管； 接管过程需要有io短暂挂起，但不致于不能用；目前还没有这样的影响生产的案例；第二，日常的监控，故障的预警； 日常要健康s