深度探讨：城商行核心业务系统存储跨中心双活建设的 10 个难点
为了帮助企业IT架构师理清和解决存储跨中心双活方案架构的难点，twt社区上周特别举办了主题交流，来自银行的同行们和厂商技术专家探讨并分享了观点。以下是精华汇总，供更多读者参考。
1、如何做到读写分离，提升IO读写效率？如何设计双活存储高可用，防止仲裁防脑裂？
@chenmingfu 宁夏银行股份有限公司 基础架构组长：
1.存储双活后，有一个难点就是热点数据的跨站访问，实施了数据库和存储层同时双活，会出现数据竞争的问题，这样也降低了IO效率。这时候就要通过锁预取和缓存策略，通过较小的控制报文，向锁权限缓存节点申请写权限，并利用锁预取将部分区间的写权限缓存到本地。这样，后续的连续写I/O操作可快速的命中在本地，减少跨站点的数据传输和交互，做到读写分离，从而提升IO读写性能。
2.AA模式的双活存储，在某些特定的多重故障下，仲裁机制会优先保证数据的一致性，可能会将双活存储上的所有LUN都停止主机访问。所以，在设计仲裁模式的时候，强烈建议建立选择独立的第三方站点作为仲裁机，但也不能完全避免上述情况，所以，还要考虑强制启动，而强制启动端的存储作为同步源端，会在链路恢复后同步增量差异数据。
@邓毓 江西农信 系统工程师：
双活的两个存储都可以同时对主机提供读写服务，也可以选择一个存储作为写存储服务，另一个存储作为读存储服务，实现读写分离，这样的好处可以减少双活存储的写I/O竞争，降低写I/O时延。双活存储高可用的话，需要设置第三仲裁站点，可以用磁盘或者虚拟机来做仲裁，仲裁机制根据存储双活方案可以选择静态优先+动态仲裁双重机制来保障脑裂或者故障后的双活存储。
@zzy3620 北部湾银行 系统环境管理：
读写分离，可以采用存储复制技术完成，也可以采用数据库软件复制技术完成，为保证数据的较高实时性，需要用两个不同的服务器挂载双活lun或者采用数据库集群，或者adg方案实现，为了保证好的IO读写效率，需要保障双活存储间的网络带宽和低延时。为避免脑裂，存储建议采用fc和ip网络多种仲裁探活机制，利用第三方站点进行检测判决。
@alphaaries 华为数据存储解决方案中心 技术总监：
要做读写分离首先要明确为什么要做读写分离。读写分离是一种技术手段，而单纯的依赖技术手段是无法解决所有问题的，如果应用的读写比例严重失调，那么需要和应用开发部门相互协调。
读写分离的重点和本质，其实就是数据的同步。为了实现数据的实时同步，现有的技术可以在多个层面实现读写分离。例如，基于操作系统层、基于存储层进行复制或者基于应用分发或者基于数据库自身的能力的技术，都可以实现数据的读写分离。由于在数据同步的过程中，通常会涉及业务数据选择以及源端多种类型整合的问题，因此通常不建议使用操作系统层和存储层的复制来实现，在金融行业，比较多的是用数据库来实现读分离。例如Oracle基于日志的复制技术等等。
2、两个数据中心间数据同步逻辑错误问题如何有效避免呢？
【问题描述】存储层面的复制技术基本以存储块为单位进行的数据复制，假设数据块发生了逻辑错误，那么存储是无法检测到的，它会继续将坏的数据块儿同步到灾备端，如果因此数据库发生宕机，那么灾备端的数据库也同样无法正常启动。
@xqhqq011 某城市商业银行 系统/灾备工程师：
虽然发生几率比较小，但这个问题确实存在。个人建议是采用磁带库或者CDP进行再次备份，若真的遇到逻辑问题还是重新恢复数据。或者干脆采用分布式存储。
@crazierspore 华为 产品总监：
无论复制方式是同步、异步、双活还是连续性数据保护，都是基于存储数据块级别的复制技术，复制源端在可读时，会将块中的数据原样的拷贝一份至目标端，当源端数据出现误删、误改、磁区退化数据异变、数据库事物层逻辑错误等数据逻辑性错误时，复制目标端无法检测到这些错误，依旧复制“错误”的数据，导致两份副本都无法正常使用。
所以要设置多层次的防范机制，保障数据的可靠性和安全性，存储双活技术只是其中的一个层次，要辅以备份技术、数据库复制技术，连续性数据保护，建立了完善的数据保障体系。
（ 1 ）备份系统按照一定的时间频率对数据库做全量和增量备份，在遇到数据逻辑错误时，通过恢复将数据回退到最后一个备份版本。如 TSM 、 NBU 、 COMMVAULT 。
（ 2 ）数据库复制技术有实时同步、准同步、异步等方式，保障主数据库逻辑错误无法正常运行时，切至备数据库，回退到备库前一个日志 COMMIT 后的版本。如 DB2 HADR 、 ORACLE ADG 、 MYSQL 主从复制等。
（ 3 ）连续性数据保护技术也是准 / 实时对存储数据块做快照，源端数据无法继续使用时，通过快照回退至前一个数据可用版本。如 CDP 。
为了不影响源端数据的访问性能或者单个系统无法满足需求时，可以考虑多种方式结合，比如备份系统在备份超大数据库时，没有充足的带宽或者备份时间窗口，可以用数据库的异步复制方式来做为备份方式的补充；连续性数据保护技术需要通过 LVM 镜像源端数据，增加了写延迟，可以通过数据库准实时同步或者异步的方式复制数据到备库节点，备库节点的后端存储为连续性数据保护的存储节点，如 DB2 HADR+CDP 的组合。
@chenmingfu 宁夏银行股份有限公司 基础架构组长：
无论是adg数据库复制技术还是存储复制技术都无法预防逻辑错误，预防逻辑错误最好的办法就只能是通过备份，当出现逻辑错误的时候，通过备份数据及备份的日志文件进行数据回滚，回滚到逻辑错误前的时间段数据。
@zzy3620 北部湾银行 系统环境管理：
因此需要进行多个层面的备份，在存储备份之外，通过数据库软件例如goldengate，adg等方式，进行实时或者准实时的逻辑备份，避免存储块错误的同步导致数据丢失。
3、双活数据中心如何保证各个业务系统之间访问路径最短？
【问题描述】双活数据中心如何保证各个业务系统之间访问路径最短？银行系统中有可以建立双活的业务系统，也有不适合双活的业务系统，当某一个业务系统同城切换演练，需要考虑那些因素而决定需要配合切换的业务系统？
@chenmingfu 宁夏银行股份有限公司 基础架构组长：
一般来说，双活数据中心架构下，一旦业务访问流量进入以后就只在当前数据中心内部系统间进行交互，尽量不要跨数据中心进行系统间交互访问，这样能确保访问路径最短且把跨数据中心间业务影响降到最低。
当单系统进行切换演练的时候，根据业务优先级，把保开门的业务所涉及的重要系统实现跨数据中心访问即可，其他非关键业务所涉及的业务系统保持关闭不提供服务。
crazierspore 华为 产品总监：
一般来说，核心业务系统相关的数据内容是优先作为双活的，其他业务系统如渠道、客户、交易结算、供应链金融、票据等根据业务优先级由科技统一规划。
具体要综合考虑本行数据中心机房基础环境、网络、系统的特点以及分批次业务系统的相关特性，综合新一代核心业务系统建设目标和项目要求，设计相对应多层业务调度框架，使用纯IP访问、动态分配负载方式的应用级双活建设部署方案。多层业务调度框架，就是在同城两个数据中心的核心网络层部署专用的全局调度负载均衡设备来专门处理跨数据中心的交易数据调度；在每个数据中心内的各业务生产区域，同样部署了区域负载均衡设备，用于对应用服务的负载均衡交付服务。
4、在存储双活设计初期，如何合理的规划双活架构，使之成为一个健康高效的架构？
@潘延晟 系统工程师：
所谓合理，其实是根据企业的自身情况而定的，业务量，技术储备，资金能力，还有双活的实际环境都决定了整体架构的不同，
目前的双活技术都比较成熟，不过却并不一定适应所有的环境。
设计初期，一定要考虑企业自身实际的情况。现有的存储环境如何， 上层业务采用的技术是虚拟化，容器还是其他， 是考虑搭建全新环境还是要考虑旧的业务系统，对比不同的技术方案的资金和技术需求，是否是企业所能承受的，是同城双活还是异地双活，双活之间的数据传输采用的运营商线路带宽的稳定性和性价比。
所以并不能简单的用一套方案来作为企业存储双活的建设依据。
@alphaaries 华为数据存储解决方案中心 技术总监：
存储双活的规划一定要依从数据中心的整体规划而实现，通常的规划分为业务规划、应用规划、数据规划和基础设施规划，存储的规划隶属于基础设施的整体规划。
在实现基础设施规划的时候，要依据自下而上、自外而内的规则来实现，即首先需要规划机房、网络，然后才会是存储产品和计算资源的规划。
所以在规划之初，需要首先了解整个业务的关联性，并需要考虑网络的整体规划，是采用边缘核心的网络设计还是边缘核心边缘的网络设计？如果是边缘核心的网络设计，将相互之间有关联的应用尽可能的部署在相邻或者相同的资源池里；如果是边缘核心边缘的网络设计，组网可以灵活调配网络资源。
除此之外还需要考虑数据中心之间的网络，距离、延时等等都是需要考虑的问题。
因此存储双活需要有非常详细的规划设计，华为在存储双活规划设计方面有大量的解决方案和交付案例。
@chenmingfu 宁夏银行股份有限公司 基础架构组长：
其实如果就存储双活来看，相对较为简单，目前主流存储厂商就那么几家，几乎每家都有成熟经验且使用案例也多，所以根据业界使用情况采用厂商的方法即可，唯一要做好的就是选择好合适的第三站点仲裁及通讯线路。
5、如何有效保证存储层双活和数据一致性，以及发生故障时如何保证前端业务的正常运行？
【问题描述】1、存储双活双活依赖的的必要条件有哪些，如发生发生故障故障或中断时的应急方案。2、故障发生时如何保证业务业务连续性和数据数据的一致性？
@chenmingfu 宁夏银行股份有限公司 基础架构组长：
1.针对存储的双活，两台存储中的不同的LUN构成双活LUN，提供给上层的主机使用，数据是从主机侧同时写入两个存储的LUN内，双活平台没有故障的时候，两端的数据始终是一致的。
2.如果存储的双活出现的故障，此时，双活平台内部有仲裁机制，从两端中会重新选举一端的存储平台作为主存储给前端的主机继续提供服务，待存储的双活修复好了后，双活两端的存储内部会自行比对，将存在的差异、增量的数据进行同步，待两端的数据一致后，继续双活对外提供服务。
3.对于双活架构下，会包含很多的层面，比如应用层，数据库层，服务器层，存储层等等，要实现真正的业务双活，必须做到每个层面都是活的，而每个层面都会有各自的技术来实现，数据的一致性也是通过这些层面采用的技术来保证的，比如数据层面采用oracle RAC，那么RAC需要解决的关键问题就是多节点进行数据访问时如何保证数据的一致性，Oracle是通过各节点间的私有连接进行内存融合（cache fusion）来保证各节点数据访问的一致性。对于存储层面，如果采用了svc来搭建双活架构，那么其数据一致性是通过svc节点之间的缓存数据同步来完成；当双活架构发生故障的时候，最主要的是避免集群的脑裂，避免脑裂的方式是一定要部署第三站点的仲裁机制，仲裁站点可以采用存储仲裁或者ip仲裁等不同的方式，避免集群发生脑裂，从而导致业务数据的不一致性发生。
@crazierspore 华为 产品总监：
一般来讲，需要考虑如下几方面内容：
6、双活存储性能影响问题如何避免？
【问题描述】双活存储系统在写入数据时，会写两次数据，尤其是通过复制功能写到远端存储的过程，传输链路的性能也会影响整体性能。
@邓毓 江西农信 系统工程师：
无法避免，肯定会影响一定的性能。这是双活存储机制必然带来的。只能尽量减少性能影响，比如减少距离，提升链路稳定性，降低写I/O频率，提升读写比例，适合写I/O时延敏感度不太高的应用等等。
@chenmingfu 宁夏银行股份有限公司 基础架构组长：
租用多家运营商裸光纤加购买独立dwdm波分设备提升链路的冗余性及链路质量，从底层通讯链路层保障跨中心通讯的稳定性，从操作系统及数据库参数层面优化存储相关参数，尽量降低性能带来的风险，无法彻底避免。
@crazierspore 华为 产品总监：
双活在保证数据可靠性的同时势必会造成一定程度的性能影响，为了保证两个数据中心存储的数据实时一致，写操作都需要等待两端存储写成功之后再返回主机“写成功”。双活 I/O 性能因为实时双写导致一定的时延增加。双活容灾解决方案提升了站点级的冗余保护，把本地的双机双柜的硬件冗余方案跨站点建设，无论是传统的集群系统、虚拟化主机平台 Vmware, 还是 Oracle RAC 等 , 跨站点建设都会无形中在业务平台中增添几分不稳定的因素。在性能方案，站点间的监测、业务会话的同步确认等的网络延迟数，加上数据同步双写的光纤延迟，都或多或少的影响了整体业务处理的性能。距离越远影响越明显，如果距离较近，也会失去建设双活容灾数据中心的意义。
针对以上对性能的挑战，华为主要从数据零拷贝、 FastWrite 功能、地域优化访问三方面来克服相应的挑战。
零数据拷贝：在双活镜像数据的初始同步或者恢复过程中的增量同步过程中，差异数据块通常有大量的零数据块，无需逐块复制，该功能叫数据零拷贝。例如，虚拟化场景下，新建虚拟机时会产生大量的零数据块，一个数十 GB 的操作系统盘，实际非零数据块仅 2-3GB 。
FastWrite 功能：对阵列间数据传输进行了协议级优化，应用 SCSI 协议的 First Burst Enabled 功能，将写数据的链路传输交互次数减少一半。
正常的 SCSI 流程中，写 I/O 在传输的双端要经历“写命令”、“写分配完成”、“写数据”和“写执行状态”等多次交互。利用 FastWrite 功能，优化写 I/O 交互过程，将“写命令”和“写数据”合并为一次发送，并取消“写分配完成”交互过程，将跨站点写 I/O 交互次数减少一半。
地域优化访问：双活数据业务场景，两站点的距离远近，是影响 I/O 访问性能的关键因素。HyperMetro 特性通过与华为 OceanStor UltraPath 多路径配合，根据双活站点部署距离，提供了两种 I/O 访问策略供用户选择。负载均衡模式 + 优选阵列模式。
7、双活方案中的NAS复制及切换问题？
【问题描述】在同城双活的建设过程中，很多负载均衡的应用需要用到NAS来实现文件的共享，满足负载均衡的需求。
1、一般的NAS都采取网络复制到同城的方案，复制的内容一般没有办法实时同步，有一定的滞后，没有办法保证数据的完全一致，一旦生产发生问题，遇到需要切换的场景，可能会丢失一些数据。有些对于数据一致要求较高的应用可能因为文件的不一致造成异常（比如一些批量作业）。请问有什么好的解决办法？
2、请问在双活的建设过程中，关于NAS的双活或者容灾有没有好的成熟的解决方案或者产品？
@chenmingfu 宁夏银行股份有限公司 基础架构组长：
如果是双活场景的话，可以考虑把nas存储也设置为双活，否则，采用主备复制的方式，nas文件系统在数据同步状态下 同城端主机是无法mount这些文件系统的，这将导致nas文件系统无法实时使用，可以根据实际nas文件应用场景区分，没必要同步的就两边分别独立挂载各自数据中心内的nas文件系统，这样也能解耦。
@LX11 华为 高级工程师：
1）当前业界已经具备NAS双活技术，NAS双活采用AP架构，使主机能够将两个存储系统的文件系统视为单个存储系统上的单个文件系统，并保持文件系统的实时双写存放和读取。
2）华为Oceanstor存储具备免网关NAS双活能力，基于多租户（vStore Pair）双活机制，可以将主Store的网络资源、协议配置及存储资源实时镜像到远端，保证两端资源实时一致。同时，该系列存储也具备SAN&NAS双活一体化能力，推荐使用。
@crazierspore 华为 产品总监：
首先看一些NAS的同步双写流程：
① 同步双写由 SPACE 发起，当有主机 IO 时， SPACE 转发给 Pair ；
② 由 Pair 根据当前状态决定是否双写，如果是同步双写，则将 IO 拆分成两个 IO ，一个由源文件系统 RIM 实际写入 SPACE ；
③ 另一个 IO 通过目标文件系统 RIM 代理转发到从端；
④ 由 EPL 根据链路进行路由，通过 TCP 或 FC 或 iSCSI 链路转发到从端；
⑤ 当从端 EPL 接收到主端数据时，找到目标文件系统 RIM ，并由其写入目标文件系统的 SPACE 。
因此有关对于数据一致要求较高的应用可能因为文件的不一致造成异常的影响， 一般由于切换时间引起。影响切换时间长短的几个因素：
1、 协议类型，推荐使用 NFSv3 协议， NFSv3 属无状态协议， NFS 受故障影响小，故障后直接重试直到响应，而 CIFS 和 NFSV4 属有状态协议，故障后还需维护自身的状态信息，遇到加锁业务时切换时间会更长甚至断业务，而且CIFS没有锁和句柄同步，对于已经加锁的文件故障恢复后没法恢复锁导致文件冲突，比如打开的文件遇到双活故障场景恢复后只能另存为文件，无法原文件保存。
2、 挂载 NFS 时需要修改协议重试的时间参数：-o timeo=XX ，该参数的单位是 1/10 秒，默认值为 600 ，建议设置成 50 ，即重试时间 5 秒。如果设置时间太短，阵列还没切换完成，会导致重试次数较多，整体时间较长。举例：mount -t nfs -o vers=3,timeo=50 /11.11.11.1/FS /FS
3、 主机上运行的业务模型，如果是加锁类业务切换时间会比不加锁类业务时间长（针对 NFSv4 和 CIFS 协议），因为故障切换流程还需保障之前加锁的业务锁释放是否完成，是否会有锁冲突，比如 VMware 或者集群类业务。为了排除是加锁影响，测试时挂在文件系统是可以加上 nolock 参数。举例：mount -t nfs -o nolock /11.11.11.1/FS /FS
4、 主机业务压力，这个原理很简单，如果主机上业务压力较大，故障切换时间就相对较长，因此测试时需要调小主机的业务压力，减小下 IO 的并发。
5、 故障方式，掉电（拔电源）是非计划内的故障，需要阵列去感知掉电故障然后走仲裁，这里仲裁还需要静默 8 秒才切换，因此切换时间相对较长，而用下电或者重启的方式进行故障则是计划内的故障，阵列可以主动通知仲裁进行业务切换，会立即进行切换，最终的切换时间只由主机协议倒换时间长短决定，大概在 5~10 秒。
6、 故障不同站点，掉电非优先站点，则无业务切换流程，只有故障处理流程，切换时间大概在 5 秒左右。
8、双活数据中心考虑哪些因素决定哪些系统适合二层哪些适合三层？是否一些基础平台适合二层？还是都建立为三层更好？
@chenmingfu 宁夏银行股份有限公司 基础架构组长：
从当前趋势来看，不同数据中心间通过三层网络互联是主流技术，如果可能的话尽量不要采用二层互联的方式连接两个数据中心，这样能让两个数据中心间解耦，将影响和风险降到最低。
采用二层还是三层技术主要取决于一些技术储备和容灾需求，比如，引入dns技术以后就可以实现dns技术加三层网络的互联切换容灾。
根据最佳实践，建议以三层互联技术为主，特殊迫不得已的情况下，再考虑采用二层技术互联。
9、存储双活对同城数据中心的选址要求？双活存储间链路的可靠性和稳定性对系统的影响及应对方案？
@chenmingfu 宁夏银行股份有限公司 基础架构组长：
1.跨数据中心通讯链路方面
购买波分设备，波分设备具备冗余高可用性，租用运营商的裸光纤，作为通讯的链路。裸光纤也冗余。裸光纤通常租用两家或两家以上的运营商线路，比如电信、联通和移动，电信的裸光纤也需要冗余，联通的裸光纤也需要冗余，防止单根裸光纤意外割断或者损坏。然而单家运营商的裸纤都通常在一个弱点井中，一起意外割断的事情常有，所以需要两家运营商互相冗余。这两家运营商裸纤的路线还不能一致，弱电井需要在不同的街道，并且分别走不同的路线到达目的地。
2.通讯链路质量方面
链路质量包括光衰、抖动和带宽等。一方面，光衰和抖动无法控制，只能靠波分设备去探测，发现光衰和抖动，立即中断该链路，切向备链路，这对后端的 SAN 网络无感知，但对波分设备的要求很高，需要购买和建设时注意。至于带宽，可以监测，达到带宽预警阈值后，可向运营商申请提升带宽。另一方面，对于链路质量的监测机制一定要在建设存储双活或者其他双活之前建立，由于是运营商的链路，链路经过了多少中继、多少设备我们是不得知的，我们只能在波分端建立有效的监测机制，有些波分设备也有专门的监控软件支持。而且也要要求和运营商建立监测联动机制，运营商监测到链路质量（是质量而不是中断）有问题，也需要第一时间告知，做出合理的决策。
3.存储双活控制器的机制
由于跨中心的双活控制器间的通讯是实时的，完整写周期必须两个站点的控制器都完成写操作。他们间的通讯又是靠链路完成的，链路质量和链路中断都将导致性能波动甚至超时，对于中断，控制器的处理机制都还不错，对于质量，控制器的处理机制往往不够，需要长时间的尝试，才会做出合理的决策，甚至没有决策， 导致上层数据库或者应用磁盘 IO 超时，而异常挂起甚至宕机。所以这个机制是决定好的双活体系的重要因素，有时候宁可立即放弃一边，也要保住 RTO。
4.存储上层 OS、应用和数据库合理的超时参数
OS 识别磁盘、应用访问文件系统、数据库访问裸设备或者文件系统，存储 IOHANG 住，将导致层层超时，尤其是数据库，超时将彻底中断宕机，甚至出现逻辑损坏等莫名奇妙的问题。有时候超时响应慢是可以等，而不是中止，所以需要OS、数据库层进行合理的超时联动设置。
5.尽量避免跨站点读写频率
没有跨站点读，就意味着本地可读，对链路质量没有要求；减少跨站点写频率， 就意味着，性能影响弱化，被控制器、数据库、操作系统等层层缓存暂存的写数据，会减少跨站点写的次数，进一步弱化链路质量所会带来的影响。没有跨站点读，就意味着本地可读，对链路质量没有要求；
@alphaaries 华为数据存储解决方案中心 技术总监：
基础设施的架构设计取决于上层应用架构的设计，同城数据中心的选址需要结合应用TIMOUT设计和规划，然后选择适当的距离。
双活架构通常会采用仲裁机制，也就是由仲裁盘，如果链路稳定性不好，经常发生超时的现象，就有可能造成双活数据不断地仲裁，严重时可能会发生脑裂的现象。因此建议双活数据中心之间的距离不要太远，其次选择信号稳定的电信运营商，最好是多家运营商共同来保证链路的冗余。
10、按照什么原则梳理现有应用业务系统，降低对双活的要求，减少投资？如何按照功能区规划存储独立或共享使用？
@chenmingfu 宁夏银行股份有限公司 基础架构组长：
应该根据信息系统重要级别分类来梳理定位，比如:一般金融行业会根据容灾需求及保护投资的原则，把信息系统划分为三个或四个等级(比如ABCD)，优先考虑A类系统(如核心系统，柜面系统，支付系统，互联网类系统等保开门系统）双活需求，双活应该重点考虑保开门系统，其余系统看暂时忽略，未来投资允许的情况下再考虑非关键系统的双活需求。
在性能iops满足的情况下，存储设备可考虑充分组合复用，无需考虑单系统使用独立存储，这样既能满足业务需求也能最大化利用设备，一般城商行业务压力不大，存储建议尽量整合使用。
@alphaaries 华为数据存储解决方案中心 技术总监：
通常的业务系统分析是依照业务等级的重要程度进行分级，大型国有银行通常可以分成A+、A、B、C几大类，其中A+类系统主要是核心系统例如清算结算账务等信息，A类系统主要是跟交易相关的信息，BC类业务主要是管理类的系统等等。
双活数据中心是为了更好的解决业务系统高可用性，因此在规划双活数据中心的时候，可以优先选择业务等级较高的业务系统，这样才会对银行的现有信息系统进行更好的保护。
双活数据中心可以通过操作系统层、网络层、存储层以及数据库层等多种方式实现，但是从易用性以及从可靠性方向考虑，业界通常是通过存储层和数据库层相互结合的方式来实现双活。存储双活也可以通过多台存储形成存储资源池，两个数据中心可以分别部署一个资源池，然后应用可以混合部署在两个资源池中使用。华为目前在数据中心架构规划方面，有大量的项目交付案例。
点击阅读原文，有更多精彩交流内容
觉得本文有用，请转发、点赞或点击“在看”，让更多同行看到
欢迎关注社区 “存储双活”技术主题 ，将会不断更新优质资料、文章。地址：https://www.talkwithtrend.com/Topic/1431
下载 twt 社区客户端 APP
长按识别二维码即可下载
或到应用商店搜索“twt”
长按二维码关注公众号
*本公众号所发布内容仅代表作者观点，不代表社区立场