面对典型数据场景下的存储架构选型如何设计？|《迈向YB数据时代》
面对典型数据场景下的存储架构选型如何设计？|《迈向YB数据时代》
talkwithtrend
talkwithtrend.com社区（即twt社区）官方公众号，持续发布优秀社区原创内容。内容深度服务企业内各方向的架构师、运维主管、开发和运维工程师等IT专业岗位人群，让您时刻和国内企业IT同行保持信息同步。
一方面，不同行业会有自己典型的业务场景特点，另外一方面，不同行业会有一些因为数据处理特点相同而有共性的技术场景，比如批量处理、报表分析、内存处理等等。这些场景是由于技术层面的数据处理流程、方式、量级等方面形成的共性系统，如何剥去行业的差异，获取到其对数据处理的共性要求，选择合适的存储平台是应该考虑的核心问题。
本期为大家带来 《迈向YB数据时代》 2022年秋季刊“架构选型 ”栏目 中的 议题三 ：
面对典型数据场景下的存储架构选 型如何设计？
谢茜茜 江西银行 信息科技部系统管理岗资深运维工程师：
存储系统作为IT系统的底层基础架构，存储技术进一步发展和推广对于整个信息产业具有重大意义。在数字化转型过程中，存储系统作为底层基础架构，其架构设计过程需被重点关注。对于金融业来说，不同业务场景应进行合理的存储架构选型，以起到对上层架构的支撑与补足作用。不同的业务系统对数据存储的可靠性要求、隔离性要求并不相同，因地制宜地进行存储选型规划是急需探讨和解决的问题。
一、金融行业联机交易业务场景特点
对于金融行业联机交易处理数据库OLTP场景，从数据库角度看：每个事务的读、写、更改涉及的数据量非常小，数据库的数据必须是当前的，所以对数据库的可用性要求很高。同时有很多用户连接到数据库、使用数据库，要求数据库有很快的响应时间，通常一个事务会在几秒内完成。
从存储角度看，每个I/O非常小，通常为2KB至8KB，访问硬盘数据的位置也非常随机，至少有30％的数据是随机写操作，而REDO日志写入非常频繁。
综上，OLTP场景下最考验的是小IO随机读写性能，要求在高IOPS下有稳定的低时延。
二、存储架构概况
1.存储技术架构
现有存储系统从底层到上层由存储介质、组网方式、存储协议和类型、存储架构、连接方式五个部分组成，整体架构如图1所示：
图1 存储技术架构图
1.1 组网类型
按组网方式，存储系统可分为IP组网存储、FC组网存储、IB组网存储等。
･ IP组网存储：指采用以太网技术进行组网的存储设备，常见速率包括1Gb、10Gb、25Gb、100Gb等；IP组网的兼容性较好，建设成本较低。
･ FC组网存储：指采用FC光纤技术进行组网的存储设备，常见速率包括8Gb、16Gb、32Gb等；FC组网的效率较高，但采购成本和维护难度也相对较高。
･ IB组网存储：指采用InfiniBand技术进行组网的存储设备，常见速率包括40Gb、56Gb、100Gb、200Gb等；IB组网的延迟较低、速率较高，但采购成本相对较高，组网的扩展性也较弱。
1.2 存储类型
按存储类型，存储系统可分为文件存储、块存储、对象存储、其它存储等。
･ 文件存储：指自身构建文件系统后，通过互通的网络提供给服务器或应用软件使用，支持数据文件读写和文件共享服务的存储设备。文件存储的常用协议包括NFS、CIFS、FTP等。
･ 块存储：指将物理存储介质上的物理空间按照固定大小的块组成逻辑盘，并直接映射空间给服务器使用的存储设备。块存储的常用协议包括SCSI、iSCSI、NVMe等。
･ 对象存储：指采用扁平化结构，将文件和元数据包装成对象，并抽象成网络URL，通过HTTP协议直接访问的存储设备。对象存储的常用协议包括S3、SWIFT等。
･ 其它存储协议：包括在大数据存储中广泛使用的HDFS协议，以及表存储协议等。
1.3 存储架构
按存储系统架构，存储系统可分为集中式存储和分布式存储。
･ 集中式存储：指基于双控制器或多控制器架构的企业级存储系统，具有较强的纵向扩展（Scale-up）能力和一定的横向扩展（Scale-out）能力。集中式存储的特点有高可靠、高可用、高性能等。
･ 分布式存储：指将商用服务器上的存储介质虚拟化成统一的存储资源池来提供存储服务。分布式存储的特点有高扩展性、低成本、易运维、和云紧密结合等。
2. 软件定义存储
大数据、云计算和虚拟化等技术的出现，使得传统的IT架构难以满足企业日益增长的数据存储需求。为应对这一挑战，软件定义存储（SDS）应运而生，打破了传统IT系统复杂和繁冗的现状，优化了网络的可扩展性和管理方式。
软件定义存储产品在提供高可靠和高可用服务能力的同时，集成了数据智能处理和分析能力，简化了海量数据处理所需的基础设施，实现数据互通、资源共享、弹性扩展、多云协作，有效降低用户的使用成本。
三、存储选型策略
1.产品选型规划
在选型过程中首先应根据业务需求确定存储形态。如果是传统关系型数据库类应用，对数据可靠性、业务可用性和时延要求较高，集中式存储阵列依然在此类应用场景中广泛使用。如果对于存储性能和容量扩展性要求较高的应用场景，则分布式存储架构更加适合。
接下来还需考虑存储的性能需求。除了存储设备本身架构设计的因素外，存储介质可能更直接影响块存储最终能够达到的性能。全闪存储节点可提供更低的时延、更高的IOPS、更高的可靠性和性能，适合于对性能要求较高的核心业务系统。在性能需求一般的业务场景，混闪的配置能提供更优的性价比。
完成存储形态和存储介质的选型后，对于分布式架构的存储设备，通用模块的选型主要基于以下几个方面：
1）网络传输设备：存储的网络环境目前主流仍然是10Gbps网络，但伴随着终端网络带宽的不断提高，未来对存储数据在网络上传输需求的带宽也会越来越大，基于未来的发展应优先考虑相对成熟的25Gbps、100Gbps网络。
2）业务逻辑层设备：此层设备主要工作是处理存储业务产品功能逻辑，主要资源消耗点在CPU，参数上更多核心更高主频可以带来更好的处理性能。
3）元数据设备：元数据作为整个存储系统的一个核心部分，整体性能的高低直接影响了存储的响应能力，设备选择上优先要考虑基于NVMe协议的全闪存储用于存放海量元数据，同时较大的内存也可以进一步提升元数据处理的响应速度。
2. 业务选型规划
业务规划主要考虑容量的规划和功能的规划。
1）容量规划。考虑不同的场景、性能需求、容量需求需搭建的集群规模，以及后续扩容，置换的规划。更应考虑到未来业务增长，在给业务划分容量时需预留足够的空间。同时还需要综合考虑业务的需求，划分不同的存储池，做到业务隔离并防止资源争抢。
2）功能规划。若只需满足基础要求，基本所有类型存储都可选用；若有容灾规划，则可选用具有同步异步复制功能的存储。对于软件功能的规划，伴随着新硬件产生和技术的进步，软件功能也要有相应的升级。
3. 部署选型规划
部署规划是结合业务的场景和可靠性要求等条件，对机房、机柜、交换机、网络等设备进行统筹考虑。存储服务的部署要结合实际物理条件综合考虑部署架构以实现服务的高可用，需要从分散性、高性能、扩展性及可维护性方面进行规划。
1）分散性：存储服务的核心就是数据的可靠性与服务的可用性，基于这两点所有服务的组件部署都要考虑到多可用区（AZ）的部署方式，确保所有服务集群在单个AZ故障时依然有集群在线提供服务，同时后端存储服务优先要考虑三AZ部署(典型分布式存储服务为三副本或纠删码，集中式存储服务为双活、两地三中心部署等)。
2）高性能：集群初建时业务体量尚未成型，此时选用大容量介质建设目标容量集群会因为介质数量太少，在突发业务压力下导致单个存储介质到达性能极限，进而影响了整个存储集群的性能，基于这种场景可以选用多个相对容量较小的存储介质提高集群的整体性能。
3）扩展性：设计之初各服务模块应充分考虑横向扩展能力，扩展模型是否足够简单，确保可以通过扩展满足未来业务的需求。
4）可维护性：传统存储运维面对大规模的存储集群，从变更到日常故障巡检都要消耗大量的人力，运维向智能化转变是未来发展的方向，通过智能运维来大幅提高存储系统的自运维能力，降低运维成本。将运维人员从繁杂的工作中解放出来，将更多的精力集中在运维系统的开发和完善上。
四、总结与展望
数字经济时代，数据存储系统作为信息化系统的基础设施，构建一套稳定、高效、满足未来业务发展需求的数据存储系统将是企业和组织夯实数据底座、挖掘数据价值、释放数据潜能的关键，笔者认为未来存储产业生态呈现出以下三点趋势：
1. 底层软硬件平台多元化
芯片、服务器、存储介质等通用技术的发展改变了存储架构，为存储行业的发展奠定了基础。存储软硬件的通用化使得存储可以选择更多的软硬件技术，充分利用新型软硬件红利的同时，也让用户享有更多的选择权。
2. 基础设施云化
在云计算基础设施中，通过虚拟化存储、计算和网络，将通用的物理资源整合池化成逻辑资源，并对外提供服务，以软件定义的方式快速、敏捷的将基础设施资源以服务的方式提供给用户，满足企业在数字化转型中对敏捷、灵活、快速、高效IT系统的需求。
3. 上下游生态融合
未来数据存储系统必须具备高性能、高可靠性、高扩展性等多种能力。既可以满足数据库等传统核心业务需求，也可以支持大数据分析、虚拟化、容器、云平台等新业务应用。在云计算、大数据技术的驱动下，不同类型企业的应用场景对性能和可靠性的要求越来越高，企业用户对存储解决方案提出了全新要求。
赵海 某金融系统 高级主管：
金融行业的批量业务在互联网模式影响下，在数据量和业务类型上都面临了巨大的挑战。这必将在数据处理方面带来对容量、效率、逻辑等方面的巨大挑战，这也必然导致金融企业选择在坚持传统数据架构为基础的前提下寻求更先进、更契合的数据存储解决方案。
提起批量业务，从事银行业科技的人员都会非常熟悉。白天的柜台、终端以及其他渠道的交易业务需要实时修改账户信息，晚上需要跑批来完成例如账务清算、利息计算、报表生成等系列业务。这就是银行典型批量业务需要完成的事情。而对于其他的保险及证券等金融行业，同样会有类似的批量业务。
通常金融行业业务系统产生的明细数据要经过加工处理，按照一定逻辑计算成需要的结果，用以支持企业的经营活动。这类数据的加工任务一般会有很多个，需要批量完成计算。大部分业务统计都会要求以某日作为截止点，而且为了不影响生产系统的运行，跑批任务一般会在夜间进行，这时候才能将生产系统当天产生的新明细数据导出来，送到专门的数据库或数据仓库完成跑批计算。第二天早上，跑批结果就可以提供给业务人员使用了。和在线查询不同，跑批计算是定时自动执行的离线任务，不会出现多人同时访问一个任务的情况，所以没有并发问题，也不必实时返回结果。但是，跑批必须在规定的窗口时间内完成。比如某银行的跑批窗口时间是晚上到第二天早上，如果到了早上跑批任务还没有完成，就会造成业务人员无法正常工作的严重后果。而且跑批任务涉及的数据量非常大，通常是需要很多系统的数据，同时包含历史数据；计算逻辑通常非常复杂，不仅处理较长、步骤较多、而且计算频繁，是需要在某些业务模型基础之上去完成的；跑批时间经常是以小时甚至更长时间粒度来计算的。随着业务的发展，数据量还在不断增加，跑批数据库的负担快速增长，就会发生整晚都跑不完的情况，严重影响用户的业务，这是无法接受的。
二、金融行业批量业务的数据管理要求
2.1 数据处理量级提升的要求
近些年来，对金融行业批量业务挑战最大的可能就是数据量的剧增了。以某消费金融公司为例，该消费金融公司于2015年营业，截止到2020年，历经4年多风雨，总注册用户数8000万，活跃用户数2500万，账务系统的核心表累计数据量已达到单表15亿行以上，而且还在高速增长中。这是大多数金融企业面对互联网业务时都会遇到的巨大挑战。很多金融行业批量业务系统在面对海量数据的不断挑战，数据库从传统的Oracle单库模式走向集群模式，从单表单库走向分库分表切片模式，甚至开始选择NoSQL、NewSQL解决方案；基础架构从从前的小型机走向一体机，从一体机走向分布式模式。
总而言之，金融行业批量业务在当前以及未来一段时间内面临的最大挑战还是数据量的升级，这必然要求数据处理层面具备更强的数据容纳以及过程处理能力。
2.2 数据批量读写效率提升的要求
对于金融行业的批量业务，从业务层面来讲，它是账务清算、利息核算、报表分析之类的分析业务。从数据处理层面来讲，它是对多系统多维度数据进行读取、归类、统计、分析、写入的整体过程，里面伴随着大量的顺序读写全表操作，数据量会非常大。而传统的关系型数据库最忌讳的却是数据库当中的全表扫描操作，当单表数据量达到一定程度之后，必然会影响数据库的整体检索效率，这二者之间似乎是有不可调和的矛盾。于是行业内企业开始寻求相应的解决方法，一方面通过各种方法来提升数据处理平台本身对数据读写的处理效率，例如利用全闪存储架构从物理层提升数据的处理效率，利用分布式存储架构来提升存储引擎的吞吐效率；另外一方面通过对业务逻辑及模型的革新创新来寻求新的整体解决方案。
2.3 数据处理逻辑多样化融合的要求
以银行的批量业务为例，传统的批量业务系统，无论是账务类的总账跑批，还是监管报送类的报表跑批，它们都是基于传统的二维关系数据模型，跑批的逻辑都是基于银行特有的业务模型。这种模式下的批量业务都会涉及到数据一致性的问题，典型的场景就是外键关联的场景。当我们对其中一张表的数据进行更改的时候，如果它有相关的外键约束或者关联约束，那么必然会涉及数据库对数据一致性的检查及处理。对于传统的账务类批量来讲，这是必然的选择，但是对于其他统计分析类的报表类批量业务，尤其是基于互联网业务系统数据设计的批量报表业务，对数据间的相互约束并不敏感，而是聚焦数据在其他维度的总体特征分析，因此某些列式数据存储解决方案反而更契合。
因此，金融行业在坚持批量业务系统既有载体架构方案升级改善的同时，探讨新型的数据处理解决方案，并且能将这集中元素应用到数据后台批量业务当中，是一种必然的趋势。
三、金融行业批量业务存储架构选型技术分析
3.1 列式存储的存储方式与批量查询之间的契合点
对于某些需要根据字段特点进行统计、排序、筛选的批量分析类业务，列式存储的效率要比行式存储的效率高很多。数据量越大，这个优势越明显，到了单机资源无法处理的规模，这个优势就更加突出了。但是如果遇到需要精准定位到某一条数据，并且进行多字段处理的场景，列式存储就显得笨重很多。以传统关系数据库为载体的批量业务系统，必然会涉及到相关的外键约束或者关联约束，这会带来两个问题：
一是数据处理效率的问题，关联约束的检查及关联操作必然带来多余的操作代价。
二是数据处理过度依赖单节点资源，无法实现分布式处理。既然我们要顾及数据之间的横向联系，那么必然导致数据无法切分，分布式处理也无法保障关联约束。
而列式数据库的原则是要抛弃数据之间的外键关联约束，希望将数据切分为相互之间独立的数据表。这样的优势有很多，首先我们可以对数据进行切片，无论是通过哈希算法还是通过其他算法，数据更容易切片交由不同节点分布式处理。其次，当我们对数据进行批量的插入、删除、更新的时候，我们无需付出不可估量的关联性代价。或许在数据量可观的情况下，这个优势不会被人过于关注。但是一旦当数据量的处理超过单节点资源能够完成的边界，我们唯一可以选择的就是列式存储，甚至我们不惜花费大量的开发代价去改变业务逻辑，使之前下沉到数据库的关联性约束上浮到业务控制层面。
3.2 列式存储与数据存取效率的契合性
首先，列式存储最大特点在于其数据压缩消重的优势，因为按照现实世界的特点来看，大部分重复数据在某一个维（列）上，那么这就给了列式存储消重最大的优势。在一片连续的物理存储空间上处理一些重复数据，总比在杂乱无序的物理存储空间上处理一些随机的重复数据要提高很多效率。这个效率的提高带来的是CPU、内存、磁盘等各个资源的代价减少。
其次，当我们要对数据的维和度进行具体的OLAP分析的时候，我们需要把大量的数据读入到内存进行深度的处理，比如排序、分类、分组、筛选、统计等等。从物理存储读入数据到内存本身的效率是非常可观的，在内存当中处理少量的数据要比处理带有重复数据的大量数据要效率得多。很多事情就是因为这不同环节上的少量提高而发生了整体上的指数级别的改变，将不可能变成可能。或许我们可以通过微观和宏观的理论来解释其中的细节。
再有，忽略数据字段之间的关联性的列式存储解决方案，使得数据具备了切片分库的基本条件，也具备了分布式架构的应用前提，而且分布式的扩展性会更好，无疑这又提高了批量系统对数据处理的整体吞吐量和引擎的整体处理效率。或许我们可以说这个是通过牺牲了数据的完整性约束来换取的，如果业务本身没有这种需求，我们丢掉这个特性换取 “分布式”的特性，又有何妨呢？很多人可能会抬出CAP理论来讲，没错，我们承认CAP理论的正确性，但是在OLAP业务场景当中，我们看到的更多的是数据宏观维度的抽象属性，是基于大量数据的同纬同度分析之后的价值，而不在于单个数据之间的严格约束，所以这一点可以放弃，因为我们换来的是可以解决海量数据场景下的架构变革。
四、结论及展望
金融行业的批量业务在互联网模式影响下，在数据量和业务类型上都面临了巨大的挑战。这必将在数据处理方面带来对容量、效率、逻辑等方面的巨大挑战，这也必然导致金融企业选择在坚持传统数据架构为基础的前提下寻求更先进、更契合的数据存储解决方案。
刘东 东软集团股份有限公司 系统架构师：
随着“智慧医院”的建设和医学影像设备的发展，医院PACS信息系统的数据量迎来爆发式增长，对于海量数据的存储和管理是医院目前信息化管理的重点，选择合适的存储架构才能保证业务安全有效地运行。
医院影像设备中图像高清化和智能化的快速发展，导致影像数据文件激增，给医院现有的存储架构带来了极大的挑战。不仅需要海量的数据存储空间，还需要保证数据存储的效率、可扩展性、可访问性和数据安全性保护性。为医生提供必要的医疗数据影像文件查询服务，配合临床辅助决策系统完成智能化的数据处理过程。
一、PACS 系统的存储需求
PACS系统的主要任务就是把医院医学影像设备（包括MRI核磁，CT，超声，传统CR/DR/X光机等）产生的医学影像数据通过各种接口（视频采集/DICOM）以数字化的方式存储下来，同时配合智能化系统增加一些临床辅助决策功能，为医生和患者提供服务。
1．系统数据架构
医学影像设备和PACS系统之间的数据传输主要使用DICOM标准（即国际医疗数字成像和通信标准）。DICOM有专门的网关服务器，用于接收影像设备传输过来的数据。DICOM网关将数据文件按照一定的序列进行接收，形成影像文件数据集（多个.dcm文件），然后由PACS影像服务器进行统一的归档和管理。对于非DICOM设备（例如传统X光/超声/病理），设备通过视频采集的方式进行图像采集，将采集的影像转换为标准DICOM影像并与病人信息进行整合后归档到PACS服务器。（如下图2所示）
图2 数据存储架构
医院的PACS存储设备为了满足国家对医疗数据存储时效的要求，通常分为在线存储、近线存储和离线存储三种。对于在线存储设备，医院会根据自身业务的特点和数据量进行选择，满足1~5年的数据存储要求。对于近线存储设备，部分中小规模医院或者是PACS数据量比较小的医院，这部分设备通常是缺失的，该类设备主要存储一些超过5年以上的历史数据，某些医院直接使用在线存储设备进行统一数据存储。对于离线存储设备，基本上所有医院都具备，因为重要的医疗影像数据，要求存储时效为30年。对于超长时效的数据存储医院通常使用离线存储设备（磁带库或光盘机等）进行归档保存。
2．系统数据存储量
医学影像的数据量通常很大，这个大不仅包括文件的容量，还包括文件的数量。对安全性、可用性和可维护性都是极大的挑战。主要的数据存储量如（表1）所示。
每个医院根据业务类型不同，PACS系统1天可以产生数GB—数十GB的数据。
按北京大型三甲综合性医院每年200多万的门诊量计算，日门诊量约5500，平均30%的患者要做影像检查，那么CT/DR/MRI的日检查量就是1650/人次，平均每次检查常规CT扫描根据层级（16~256层）为十几MB量级，而X光机的胸片可以到几十MB，心血管或者脑部的造影图像可达近百MB以上。按平均50MB计算，那么每天就可能产生82.5GB数据，每年产生约30TB数据。如果是肿瘤类医院，那么拍片检查数量会更高，每年数据量会达到上百TB。如此大量数据的长期保存，对存储介质、保存环境、管理都是极大考验。
3．系统数据存储方式
PACS系统对数据存储的容量、性能和安全性都带来了巨大的挑战。从医院PACS系统诞生开始，各个医院就在探索经济可靠的影像存储方式。
现在主流的PACS系统一般把影像数据分为在线、近线和离线存储，这是根据数据的存储性质和需求方式来划分的，是现在PCAS系统存储的基本指导原则。目前大部分医院在线存储一般采用SSD/SAS高速硬盘，存储架构基于SAN存储或NAS存储。近线存储则使用大容量低成本的SATA硬盘，离线归档设备则使用蓝光光盘库或磁带库，为医学影像数据的长期保存带来了可实现的基础。
由于分布式存储技术的发展，服务器设备和大容量硬盘成本的下降，在线和近线存储的界限在变得模糊。为了解决PACS系统数据存储的问题，也存在一些采用灵活性更高、扩展性更强的分布式存储系统替代医院PACS系统使用的SAN存储/NAS存储。
二、PACS 系统分布式存储架构设计
在进行PACS系统的分布式存储架构设计时，应考虑访问协议、容量、性能、网络和应用访问等各个方面的要求，才能满足PACS的使用。分布式存储架构以X86服务器为节点，配置大容量数据盘和固态缓存盘，安装分布式存储软件系统，接入医院核心交换机网络，为PACS系统提供数据存储服务。
1．总体架构设计
请见下图3 总体架构设计
图3 总体架构设计
2．存储访问协议
医院PACS系统的数据存储类型主要采用两种方式。早期PACS软件系统使用FTP协议传输数据，多采用SAN存储架构。后来由于传输效率问题，目前大部分PACS系统已经升级为基于NAS存储的数据访问方案，可以支持CIFS/NFS等多种文件存储协议，要求存储系统提供文件存储服务。
3. 存储容量和性能设计
PACS系统产生的影像数据文件以非结构化文件数据为主，文件数量多，且患者单次检查在单位时间内会产生大量文件。存储系统需要短时间处理海量影像文件数据，同时保持稳定高效地访问。而且存储系统还要支持长期的数据存储需求，满足PACS系统的设计，具备高扩展性和灵活性，支持容量按需扩展，在不断扩展的单个命名空间中，提供数百TB级的存储容量，帮助医院应对大量就诊数据，不增加因扩容带来的管理开销。
在存储容量方面，由于分布式存储系统的数据保护机制采用的是多副本或EC纠删码，需要根据实际容量和性能需求采用不同的数据保护机制。多副本性能优于EC纠删码，但是得盘率相对比较低。按三副本计算，只有33.3%。，如果采用EC纠删码，以三节点配置4+2:1的EC策略进行计算，得盘率有66.6%。
在存储性能方面，医生在调阅病人的医疗影像时，不能等待时间过长，否则会影响患者的就诊体验，平均每次影像病例打开应控制在10s以内。为了保证分布式存储系统的性能，需要做到两点，即保障数据盘的数量并配置固态缓存盘。每块数据盘大约可以提供80M~100M的读写性能，一个满配的4U节点可以达到2-3GB/s的峰值性能，配置3节点以上，基本可以保障PACS系统的性能要求。但是对于大并发的数据读写请求，仍需要配置固态缓存盘，提升数据读写速度。由于缓存盘写入速度快，数据盘写入数据慢，随着大量的数据写入，没有及时写入到数据盘上的数据是会堆积在缓存盘中的，为了避免缓存盘被写满的情况出现，最佳实践是5：1，即5块大容量NL-SATA盘配置1块固态硬盘，如果是NVMe协议的固态盘，可以配置8：1。在保证数据写访问时，缓存盘不会被溢出写满。
4．存储网络设计
由于采用了分布式存储架构，网络传输带宽就额外重要。通常分布式存储系统网络分为数据网、业务网和管理网。业务网和管理网可以根据医院现有的网络情况和规模进行选择，至少采用千兆网络连接。
业务网应尽可能采用万兆网络连接，提升高峰期多个业务科室在同时访问存储系统时的数据传输效率。因为医院看病早高峰期只集中在上午四小时左右时间，大量的患者拍片检查医生阅片，下午医生只是进行报告书写等工作。当采用千兆网络时，除去其他系统业务开销，提供带宽按60%计算，只有75MB/s。如果同时有多个医生调阅影像（按50MB计算），只能同时支持打开大约2-3个文件，比较影响医生的工作效率，影响患者就医体验。
在数据网，各个分布式存储系统之间需要进行大量的数据交换，至少需要配置万兆交换网络并做端口绑定聚合，最佳实践是采用25GE网络或40G InfiniBand网络进行连接，保证各个存储节点之间的数据交换带宽。
5．存储软件设计
分布式存储系统软件主要分为三大技术路线的产品。主要包括基于Ceph的商业化软件产品，基于GlusterFS的商业化软件产品和完全自研开发的产品。
Ceph和GlusterFS都是开源存储解决方案，以上三大技术路线选用任何一个“派系”的产品，基本上都可以满足存储使用要求。但是在实际的PACS应用测试过程中，还是会有一些区别，主要说明如下：
5.1 关于存储软件的元数据架构
大多数分布式存储软件产品都有元数据盘的概念。在大多数自研架构和Ceph架构中，要求必须有元数据盘（MDS），用于提供数据索引来定位文件，同时还需要监控单元（MON）保障一致性。而在GlusterFS架构，使用了完全去中心化结构，没有元数据的概念，使用弹性哈希算法来定位文件。这种做法的好处是无需元数据服务和专门的索引数据，即可实现文件在各个节点上的读写以及均衡分布，并实现全局统一命名空间。
采用元数据架构的好处是可以提升PACS系统的大量小文件的写入性能。由于每个患者的CT/MRI检查影像数据是由几百上千个小文件组成的，使用独立的元数据盘并配置NVMe SSD，可以有效的提升文件创建速度，提升同一时间创建多个小文件时的效率。
采用完全去中心化结构的弹性哈希算法来定位文件，在文件创建效率上是不如独立的元数据架构的，因为每创建一个文件，都需要做一次哈希算法来定位文件。但是安全性相对较高，适合X光片和超声等单个大文件影像数据的写入。
5.2 关于存储软件的缓存策略
关于分布式存储软件的缓存策略机制各个厂商都有，但是主要分为本地缓存策略和全局缓存策略两个技术路线。本地缓存策略是以单个节点为单位，单个节点的固态缓存盘只能给本地节点的数据盘做加速。全局缓存策略可以将各个节点上的固态缓存盘统一做成一个缓存存储池，缓存利用效率更高，性能更好。但是需要注意的是，网络带宽一定要保证，否则各个节点之间的带宽就会成为缓存加速效率的瓶颈。
除了数据盘有数据保护机制，缓存盘也有多副本保护机制。只是有的厂商不支持个性化配置，默认采用三副本策略。有的厂商可以支持调整为二副本，虽然缓存得盘率只剩下50%，但是对于PACS的读写性能有很大提升，在缓存盘配置数量足够多情况下可以考虑采用。还有一个比较重要的缓存策略就是要求分布式存储软件的缓存盘和数据盘最好支持不同的策略配置，如果只支持同一种策略，性能和容量就不可兼得。
最佳实践的PACS系统分布式存储配置场景是缓存盘采用全局架构配置二副本或三副本策略，数据盘采用EC策略，这样性能和容量都有保障。
三、应用场景总结
PACS应用在医院众多的数字化信息系统中是比较特殊的一个，存储容量需求大，网络访问要求高，在“智慧医院”建设的大环境下，在满足患者看病的同时，还需要满足临床应用、教学、会诊和科研的需要，满足数据安全保护的需要，有完善的数据保护机制。
在做PACS系统存储系统时，需要充分考虑医院现有的网络基础设施、分级存储设备和数据存储要求。在保护医院原有投资的前提下进行合理配置。特别是采用了分布式存储架构，对网络要求比较高，需要额外配置10GE/25GE光交换机和万兆接入交换机，考虑扩展性，满足存储节点横向扩展需求，否则会影响存储系统效率。
在系统设计过程中应当遵循整体规划，分步实施，对原有SAN存储系统、冷备光盘库和磁带库等存储系统合理利用，避免形成新的信息孤岛。
本议题从联机类、影像类、批量分析类几个典型业务的角度，对其应用系统的存储架构选型设计进行了详尽的分析和说明。可以看出，由于信息系统的差异性较强，在数据存储结构、架构扩展性要求、数据读写方式等方面都存在着不同的要求，同行朋友们可以参考议题观点应用到类似业务系统的存储架构选型设计当中。
阅读更多《迈向YB数据时代》精彩内容，请识别以下二维码：
《迈向YB数据时代》
数据，作为企业最核心的战略资产，正在由于规模越来越大变成一只令人恐怖的怪兽。在人类数据应用规模即将进入YB时代的当下，如何存好、用好、管好海量数据成为大中型企业普遍面临的巨大挑战。《迈向YB数据时代》，由twt社区和华为存储用户俱乐部联合主办，凝结中国一线用户中应用创新技术专家的具有代表性、前瞻性的技术洞见、实战经验、同行共识，从趋势、架构、实施和运维四大方向，为中国大中型企业应对数据及存储管理中的重大应用挑战提供代表性的参考指南。“乘众人之智，则无不任也；用众人之力，则无不胜也。”让我们一同携手，从容迈向YB数据时代！
《迈向YB数据时代》2022年 秋季刊 以关键应用存储为主题，带领读者回归存储的基本原理，结合敏态和稳态的关键应用，通过群体专家的协同协作，分享实战的心得体会并取得共识，帮助更多的企业用户更好地针对关键应用系统如何选择和使用存储系统，明确各业务场景对存储的关键技术要求，为企业的数据应用创新提供一定的决策参考。
-
2022年秋季刊【架构选型】议题一： 银行业核心账务系统存储架构选型如何设计？
-
2022年秋季刊【架构选型】议题二： 金融机构多场景关键应用下的存储架构如何设计？
点击 阅读原文 ，到社区原文下与更多同行交流探讨 ↙ ↙ ↙
*本公众号所发布内容仅代表作者观点，不代表社区立场