集中式的全闪存+分布式对象存储+容灾VS分布式全闪存+分布式存储两种方案如何选择？

首先先说选择分布式还是集中式的问题，先说结论：在医疗行业，不论是中国排名前十的超大型三甲医院，还是床位数还不到 1000 的医院，分布式转型都是趋势，传统的服务器，SAN 交换，独立存储的方案往往只作为历史遗留系统保存，新建院区或者更新的时候，基本都是往分布式比如超融合转型的，以我们的方案为例，甚至有三甲医院把全部的 DMZ 区和内网区的全部业务和数据库都放在我们的超融合上的，原因也很简单，大致为以下三点:

1.分布式合成本可控
比如我们 SmartX 的超融合或者分布式存储 ZBS 方案，可以客户自行选择各家的服务器甚至利旧服务器，这样就免除了昂贵的独立存储和 SAN 交换成本，还能帮助客户更好的完成国产化转型（SAN 交换机没有国产的，分布式或者超融合不用 SAN 交换机，用以太网代替），而且，分布式可以小规模起步按需扩展，以我们超融合为例，三节点起步，扩容时业务完全在线，无需人工数据迁移，数据迁移是自动的，这样等到资源不够的时候，再加服务器节点就可以了，保护了投资。而传统磁盘阵列，性能达到控制器硬件上限的时候，再加盘就只能增加磁盘容量，不能增加性能了，要想升级性能，就得把整个磁盘阵列换成新的，再做有风险的人工数据迁移，这对于停机时间紧张，停机责任和数据不一致责任重大的医院来说是个风险，而且投资也更多，不但独立磁盘阵列更贵，而且需要一次规划3-5年的存储用量，占用资金也更多。

2.分布式运维管理简单
以我们超融合或者分布式 zbs 存储为例，升级固件一键完成，更新节点不需要停机，超融合可以一个界面看所有基础架构，包括虚拟化，主机，存储等，不用维护多套配置表，不但降低了运维的复杂度，也降低了运维的风险，医院本来 IT 人手就不多，又有智慧医院创新需求，因此简单省心对医院的IT管理运维团队就能帮上大忙。

3.分布式的性能能够承载医院关键业务应用（部分分布式厂商的方案可以做到，）
HIS 业务及数据库，电子病历及数据，集成平台，虚拟化资源池，综合业务等等，我们有着众多的医院都放在我们的超融合或者分布式存储 ZBS 上了，这里面不乏日门诊量超过 8000+ 的大型三甲医院也把最核心的 HIS 业务和数据库放在我们的超融合上，我们算一下日门诊量 12000+ 以上，虚拟机超过 1300 个的的超大型三甲医院，就把所有的核心业务包括 HIS，电子病历，集成平台，综合虚拟化资源池，综合业务以及对应所有业务的数据库都算上，让一套存储承载，其 IOPS加起来顶天几十万的量级，这个性能承载对于我们的分布式方案是无问题的，我们高配节点三个节点起步的分布式存储或者超融合都能达到这样的性能量级，而且超融合还能业务在线的线性扩展，线性的增加性能和资源。所以与其说医院关注性能，还不如说医院对于稳定性，可用性要求高，所以才会有使用大牌传统磁盘阵列的想法，这点确实是医院所该考虑的，也不是所有分布式厂商都能做到很好的，这点就需要医院去进行选型了，起码我们的分布式存储和超融合在头部金融/医疗/制造业的核心生产和数据库都有众多的案例和长时间的检验，金融领域是当之无愧的首选超融合品牌，稳定性和可用性这个方面 SmartX 是有较大的优势的，毕竟分布式存储的代码是从零开始自研的，产品的可控性，故障的可排查性就会占了比较大的优势。

上面说的三点是针对需要高性能的块存储的分布式的，对应文件存储，对象存储，分布式也一样是趋势，原因也很简单：
看看 DELL EMC 的 isilon，再看看其他友商的各种用于医院 PACS，数据湖的存储，包括他们的文件存储方案和对象存储方案，其本质都是分布式的存储，现在医院新建院区或者替换存储也多采用这种方案。原因也很简单，医院类似 PACS，人工智能等相关业务的文件，对象的数据增量大，如果按传统 NAS 存储去扩容，一方面是成本太高，另一方面是传统独立 NAS 磁盘阵列扩容能力有限，所以这个对于非结构化数据量暴增的医院来说，分布式是不二的选择。（当然，Isilon还是挺贵的）

现在这个分布式文件/对象领域有众多的方案和友商可选，基本上医院的态度热的 PACS 数据可能放在 NAS 上，也可能放在分布式块存储上（我们有大型三甲医院把近三年的 pacs 热数据放在我们超融合上的案例），但冷数据，归档数据，医院新建数据中心不是选择分布式的，成本有优势的大容量 SATA 盘的 NAS 存储，就是选择了对象存储（多副本无需备份，不怕勒索病毒，未来整合好了可以拓展做数据湖），至于选择哪种看医院的集成能力，因为毕竟对象存储有元数据，接口也是 rest 的，对接这个需要应用厂商加持，要不要这么搞就看医院的需求了，归档 PACS 等非结构化数据选择 NAS 和对象存储，对医院来说都是合理的。

至于是不是用全闪，看支撑的业务情况，进行选配即可。

接下来讲灾备，先说简单的，NAS 存储或者对象存储，这个从我见到的很多医院里，并没有灾备的计划，原因很简单，如果是用对象存储，本身数据就多副本了，而且对象因为是被封装了的结构，也不怕勒索病毒之类，而且还能开多版本功能，保证一次写多次读，每次变更都产生个新版本的文件，老版本的文件也保留，加上对象存储本身一般就更适合冷数据，归档的数据量又太大，似乎就没有做灾备的必要了。如果是使用文件存储，如果是热数据冷数据都存的配置，似乎买灾备存储成本也太高，所以也没有多少医院去做，如果只放的是热的 pacs 数据，则有部分的医院会考虑搞灾备，但单独灾备成本又太高，不光是设备成本，还有链路成本，多数医院会选择退一步求其次，在本地的热数据 NAS 存储做多数据副本或者 raid 来做基础的保护，我们就有大型三甲医院将三年的 pacs 热数据放在我们超融合分布式存储上保存的案例，以保证性能和可靠性，更多的归档数据则由配置大容量盘的分布式 NAS 或者对象存储保存，至于 NAS 存储对象存储配置什么级别的分布式资源池，对象是配冰川对象存储还是实时性相对高一点的对象存储，对象存储搞几个数据副本，数据副本摆哪个机房，这个就看医院的资金和需求了。

当然，真的去搞这部分文件的跨机房灾备方案也没问题，不过多数医院没把这个放在第一要务上，灾备优先还是建设块存储的和关键业务的，毕竟这才是医院最重要的系统和数据，那么接下来就讲分布式块存储或者整合了分布式块存储的超融合的灾备建设即可。

分布式块存储和整合了分布式块存储超融合和传统集中式存储的灾备架构也是类似的，该做双活，复制，备份，CDP 就做，双活该有仲裁节点还是有，oracle rac 该做还是要做，双活，远程容灾，备份链路的距离，类型，带宽要求也和传统架构差别不大，这一点倒没有明显的区别，成本上总体看还是超融合占优势，但本质无非是选择了哪种技术路线，就基于这种技术路线走下去建设灾备罢了。

如果您想了解灾备方面分布式和传统三层架构的区别，下面就引用一下回答其他客户问“超融合架构和传统架构容灾区别，如何规划两次三中心架构”的用户的答案供您参考：

容灾有多种方式，比如基于应用容灾，数据库容灾，基础架构硬件特性的容灾等，越接近硬件底层，容灾的通用性就越强，适配性也就越广，我的理解是您咨询的是基础架构硬件特性层面的容灾，而且不包括备份或者连续数据保护的 CDP 的部分，因为如果包括备份的话就叫灾备了。容灾只是指恢复物理设备或者不同物理站点级的灾难。不包括备份恢复逻辑错误，人为错误和病毒感染的部分，因此本次回答只针对基础架构容灾的这一个部分。

虚拟机层面，超融合的容灾与传统方案类似，都是基于虚拟化技术的 HA，遇到灾难时可以实现自动切换。

在存储层面，大体上和传统基础架构的容灾都类似，细节上是有一些不同的。
如传统 SAN 存储的容灾，是需要买两个同厂商同系列的存储，或者借助存储虚拟化的双活设备接到两个存储上，然后数据同时写入两个存储，相当于灾备的安全是两个存储都独立一份同样的数据，数据的复制基于同步或者异步，同步做同城，异步做跨城不限距离的，双活是在同步复制的基础上再做个同时读写和自动切换。以存储双活为例，数据的安全相当于是靠本地的磁盘阵列内的 raid +跨阵列的数据复制来保护，为了防止脑裂，需要配置仲裁节点，传统架构双活如果主机/虚拟机 HA，网络冗余，存储双活（靠同厂商的阵列或独立的虚拟化引擎硬件双活），数据库双活（oracle rac）都配置了，总体可以实现 RPO=0（出现机房灾难时数据无丢失），RTO=分钟级（分钟级自动恢复业务运行），但传统双活方案成本较高（专用存储或者存储双活硬件），管理复杂（主机，SAN 交换与存储分开管理和配置），未来升级难（基于存储阵列自身的双活更换存储如果换了其他家的硬件，只能做有风险数据迁移，并且完整购买整套其他厂商的双活相关的存储和存储虚拟化硬件）。

而分布式存储，或者加上了业务主机虚拟化部分的超融合方案是分布式的，存储变成了分布式的存储，因为分布式存储是超融合的子集，超融合包括了分布式存储，所以后面我都是以覆盖范围更广的超融合来进行说明，如果单选择分布式存储，主机/虚拟化层面该怎么做就怎么做，该做 HA 的就做 HA，双活就是主机 HA +分布式存储的多数据副本来实现的，就和使用超融合本身没有什么本质区别了，无非是集成起来更麻烦一点。

以我们 SmartX 的拉伸双活方案为例，两个同城数据中心都放超融合集群，然后通过裸光纤链接，也和传统阵列的双活一样需要仲裁节点防止脑裂（可以是虚拟机），但不需要独立的存储双活的硬件设备了，在实施完双活后，两个同城的数据中心的超融合集群的底层存储会形成一个跨数据中心的统一分布式存储资源池，相当于成为了一套同城的跨地分布式存储（超融合世界主流分布式存储的双活都是这个逻辑），这时数据会分成三份，两份存在主中心（防止少量坏盘就要自动切换至备中心），一份存在同城的异地中心，这三份数据完全是同步复制，没有数据丢失。如果出现了主机房整个瘫痪，虚拟机部分会分钟级的通过虚拟机的 HA 自动切换至容灾机房上的超融合主机上运行，存储则直接拉起容灾机房的数据副本，实现 RPO=0，即无数据丢失，以及分钟级的 RTO，即出现灾难时分钟级自动恢复业务运行，所以，超融合的可用性，是靠着跨机房的数据副本，同机房超融合的数据双副本（保护等级相当于 raid1），以及虚拟机 HA 来保障的。

当然，不管是传统双活方式还是超融合，该做共享卷的做共享卷，两边该做什么虚机就做什么虚机，该部署数据库双活的就部署数据库双活（比如 oracle rac），这一点和传统架构没有区别，需要的链路的类型和带宽，链路距离等要求也与传统容灾方案基本一致。

超融合双活方案成本相对较低（以 SmartX 为例，硬件节点可以用各服务器厂商的服务器，甚至利旧使用服务器，而且超融合集群加节点扩容是业务在线的，不需要停机或者人工数据迁移，就可以小规模起步按需扩展），管理简单（基础架构统一管理），未来升级简单（业务在线换掉旧服务器，加入新服务器即可，数据自动摆放迁移，无需高风险的人工数据迁移），因此从传统容灾方案转型到超融合的也越来越多了，如果一些特别关键的业务，要求更高的 RTO，比如秒级RTO，比分钟级 RTO 更短，那么客户一般会选择基于应用负载均衡做秒级 RTO 的方案，这个可以由应用厂商提供方案，我们也有这样的第三方合作伙伴能帮助客户实现这样的目标。

容灾还有异步复制，不限物理距离，链路也可以走以太网链路（租用链路）这一点在传统阵列上还是超融合也是类似的，我们 SmartX 的超融合方案是将快照复制到跨城区的超融合集群来做异步复制的。

至于两地三中心（同城双活，异地容灾），该如何规划，请看下图，这个架构图不只是包括了两地三中心的容灾，也包括了备份，CDP，甚至包括了虚拟机之间的网络安全管理以及应用级双活的方案。这个架构图中全部的技术（如备份恢复，同城双活，异地容灾，虚拟机东西向网络安全等），我们都可以靠我们自己研发的超融合的相关方案实现，而 CDP，应用级高可用方案，我们也有合作伙伴可以实现，若有兴趣，可以约我们进一步进行咨询。这个图是我们超融合在选择了自主研发的支撑金融级业务的免费 ELF 主机虚拟化时的情况，如果我们超融合选择使用了 VMware 主机虚拟化则更简单，一句话就概括了 ： “凡是VMware支持的灾备方案，我们全部支持”，原本 VMware 虚拟化的灾备和安全方案和生态就已经很成熟了，没必要单独画一张图。至于具体的资源池规划到多大，比如超融合集群什么配置，多少个节点等，那就需要我们进一步详细沟通才确定得了。