查看其它 1 个回答baizhaoxian的回答
1.首先最“突出”的难点就是性能影响问题。
传统的集中式主备存储架构，在主存储写入数据时，需要将数据同步一份至备存储，完成后算是一次完整的写周期;而双活存储架构则不一样，两个存储虽然都同时受理写请求，也会将写入的数据同步一份至另一端，但关键点在于两个存储并不同时对同一个存储块写操作，也就是说写同一个数据块时，抢占成功的存储会对该存储块加一道“锁”，防止被另一端写，另一端想要读该数据块，也得乖乖等数据同步完成之后才能进行，所以这样看来，双活存储虽然物理上实现了双活读写，但实际的读写性能上，由于存在着大量的“等待锁释放”和“数据同步完成”两个动作，造成了性能的影响。
这个影响面跟什么有关系呢?
第一个动作取决于写操作的频繁度，也就是写IOPS，写 IOPS 越高，锁竞争现象越严重;第二个动作取决于两个存储间的距离和存储缓存的大小，距离越远，写同步往返延时越高，存储缓存越小，写缓存延迟现象的比例越高。
然而核心系统正是由于业务集中度和并发度高，对读写响应时间也特别严格，特别是对流水表的写入操作，如果两个存储都同时承担着高并发地对这些集中式的数据表读写的任务，那造成的锁竞争现象将更加严重，再加上本身两个存储间距离原因导致的延时，性能影响将成倍放大，轻者业务处理缓慢，重则核心系统直接瘫痪，核心系统如果难以破解该难点，也将无法使用存储双活技术。
2.其次最具“风险”的难点就是脑裂与链路隐患问题。
一方面，在传统主备存储架构中，由于两个存储间的关联是松耦合的关系，存储与存储间心跳探测也只是为了保证数据同步，心跳链路中断也只是数据复制中断而已，并不会造成实质的存储切换等动作，最多会因为中断，造成主存储的 IO 短暂HANG住，对业务也几乎无感知。然而倘若升级为存储双活架构，由于整个架构呈现的是一种对称式的架构，两个存储都是作为主存储，必然需要一个第三方的仲裁设备，在存储间链路中断时，来投票选举出存活的主存储，不至于因两个存储互相争抢主动权，而造成两败俱伤的惨烈局面。
然而问题就在于此，当发生脑裂现象时，仲裁之后存储恢复时间需要多久?
这个时间取决于投票表决的时间和竞选失败的存储前一刻的 IO 吞吐量，因为竞选成功的存储需要将这部分 IO 回退来保证业务数据的一致性，而核心系统存储的 IO 吞吐量无疑是非常大的，尤其是在晚间批量时，这也将意味着当发生链路中断，为了防范脑裂，需要将整个存储 IO HANG 住，并且这个 HANG 住的时间也因为是核心系统变得更长。
而矛盾点却在于，核心系统是最重要的系统，对业务连续性的要求比任何业务系统都要高上一大截，链路中断造成的 RTO 太长将无法接受，更令人恐怖的是，如果此时正处晚间核心系统批量，那第二天白天还能否开业就真的是一个问号了，所以换句话说，建设核心系统存储双活需要保证高可靠的链路，无论这个链路是本地还是跨中心的，只有这个最重要的前提条件具备了，才能开始着手存储双活。
另一方面，如果双活存储间的链路是跨中心的，还需要考虑链路的稳定性问题。由于这个链路通常是租用运营商的裸光纤，光衰问题和抖动问题也是目前无法解决的难点，一旦发生于核心系统，性能受影响不说，如果因此触发脑裂仲裁，造成 IO HANG 住，又是一场全局性的灾难，所以核心系统上跨中心的存储双活更是难上**加难。
3.最后最具“考验”的难点就是存储架构转型过程问题。**
如果前面两道鬼门关要么因自身企业核心系统 IO 压力不大，业务连续性要求不高而“ 不太在乎”，可以靠着软硬件技术而“化险为夷”，那在将传统存储高可用架构转型为双活存储架构时，依旧存在些许技术难点的考验。
表现为：在存储双活技术选型时，该技术是否为真正的存储双活?而不是备存储将 IO 转发至主存储的模式，该技术的成熟度和稳定性如何?是否能够保护原有存储投资?能否支持两地三中心扩展?等等;在存储双活实施过程中，巨量的核心系统数据如何快速同步到另一份存储副本?完成同步之后的两个存储副本以怎样的方式挂载给多台核心系统主机?是两个副本再虚拟成一个卷共享给主机还是分别挂给不同的主机?实施时，是否需要停止核心系统，停机窗口如何安排等等;在存储双活运维时，如何实时监控存储双活的性能状况，遇到紧急存储故障或者链路波动时，应急措施是怎样的，是否需要人工干预，需要人工干预时，采取哪些应急解决办法等等。
以上问题一个个接踵而至，都是在转型存储双活架构时，需要事先进行周全缜密的考虑， 只有通过了这层“考验”，方能大胆放心的着手核心系统存储双活优化。