【摘要】随着近年来互联网技术的深入发展，非结构化数据呈爆炸式增长趋势，为满足大量非结构化数据的存储和管理需求，存储厂商适时推出了对象存储解决方案，本文首先介绍了对象存储的相关基础知识、与传统存储的差异、数据冗余技术和数据容灾技术，然后笔者就所在单位非结构化数据存储平台建设实践和非结构化数据管理运维，与大家一起分享，共同探讨。
【作者】
zhangjunxi570（社区ID ，目前就职某城商行科技部系统管理工作，现长期负责存储及容灾体系的设计运维。
王金东，目前就职某城商行主要负责数据中心基础架构规划、建设和运维管理，具有多年的数据中心建设和运维经验，对主机、存储网络和备份具有深入的了解。
随着互联网技术的深入发展，传统的金融行业以互联网相关技术为基点，紧抓机遇迎接挑战，加速推进移动互联网、大数据、云计算和人工智能等新技术、新业务和新生态的发展，使得各种数据正迅速膨胀并变大，数据呈爆炸性增长的趋势。特别是近几年，疫情深刻影响着各行各业，金融行业在研究如何提供更加丰富面向互联网体验良好的无接触服务场景，由此产生的多媒体格式的数据更加速了数据的增长趋势，需要新的基础技术来支撑。与此同时传统的影像、日志等业务场景数据体量日益庞大，导致管理运维的复杂程度快速增长，传统的文件系统管理缺陷逐渐暴露，问题日益突出。创新的需求和传统的场景落实到基础架构层面需要重新认识和应对非结构化数据的管理工作。以下是结合我们实际工作经验进行的应用实践总结，供更多同行参考。
传统的金融行业信息系统，通常以表单的形式进行数据的交互，并将数据相关内容存储在数据库中，并且因原来存储磁盘容量较小、价格偏高，也仅仅只保留交易和管理类结构化的关键数据，传统的数据中心信息系统主要是烟囱式，系统扩展性差。随着集中作业、影像存储和理财双录等新业务形态的快速发展，大数据、机器学习、IoT设备、面向互联网及移动终端的场景化交互式应用等各类场景、行业正在快速生成非结构化数据。传统的文件系统存储在应对PB甚至EB级数据时会逐步突显出访问性能严重衰减、扩展性差、扩容成本高等诸多问题。尤其在金融行业达成保障数据高可用基本目标，利用传统的磁盘RAID、副本及镜像等技术时，会放大相关 入。在这一背景下，对象存储通过一种全新的存储技术手段提供了满足海量非结构化数据存储和访问的需求。
非结构化数据是指那些无法简单的组织整理以便于存储在关系数据库里面的数据，通常划分为文本型和非文本型非结构化数据。文本文档、演示文档、日志记录和电子邮件就是典型的文本型非结构化数据。非文本型非结构化数据的例子包括 视频、图像和音频文件。大量的非结构化数据的产生，需要一种管理简单，又安全可靠的方式进行数据的存储管理，对象存储就是适应这种需求产生。
对象存储（通常是指基于对象的存储 是一种用于存储大量非结构化数据（object 的存储体系结构。从实现形式上讲，对象存储通过利用分布式的X86服务器集群加高速的局域网构建成一个易于扩展的高性价比的存储架构体系。对外提供RESTful API接口，可以被应用程序直接访问。同时引进了先进的纠删码技术，在可用空间损失很小的情况下提供了足够媲美传统RAID和副本方案的数据可靠性。
对象存储在结构和使用上与传统的块存储和文件存储有着明显的区别
如图所示，块存储就是在物理层这个层面对外提供服务，通常是多个磁盘组成一个LUN，LUN可以看作为裸盘，不能被操作系统直接访问，需要根据需要格式化使用，并建立文件系统才能被访问使用，块存储的访问单元为“块”，块存储一旦被一个系统使用，就独占了，不能被共享；文件存储，就是在文件系统一层对外提供服务，通常由多个LUN组成一个文件系统，系统只用访问文件系统一级就可以，访问单元为“文件”，通过CIFS 者NFS协议进行共享，各个系统都可以根据接口去访问；对象存储，也是文件系统一级提供服务，只是优化了目前的文件系统，采用扁平化方式，弃用了目录树结构，便于共享，高速访问。对象存储一定是分布式存储，可以跨站点组成一个全局对象存储池，通过Restful HTTP接口实现随时随地访问，分布式的架构简化的存储扩容方式，空间易于扩展。
如表所示，对象存储与我们熟悉的块存储、文件存储之间在使用上有着明显的差异，因此适用的场景也有所不同。对象不支持对数据进行部分修改，只能整体写入，上传同名的文件不会覆盖原文件，只更新版本信息。因此对象存储不适合数据库、需要被频繁修改的文件等场景。但是对象存储也具有其他两种存储不具备的优势，标准的S3协议符合REST规范具有互联网应用友好性，节点扩展非常便利容量和性能同步增长。
块 | 文件 | 对象 | |
支持的更新类型 | 局部更新 | 局部更新 | 整体覆盖 |
支持的文件数量 | 文件数量几千万 | 文件数量几亿 | 对象数量可以到几千亿 |
存储协议 | SCSI、Fire Channel、SAS | CIFS、NFS | Rest Http:S3、Swift |
元数据支持 | 固定属性 | 固定属性 | 用户自定义元数据 |
适用数据类型 | 结构化数据，交易型数据库本地访问 | 非结构化 数据，频繁修改，本地访问 | 非结构化数据，可以整体覆盖远程访问 |
优势 | 高性能 | 易于访问 | 易扩展，跨站点分布式访问 |
限制 | 成本高 | 难以跨中心扩展 | 不适合需要被频繁修改的数据 |
2.3 对象存储数据数据冗余技术
本文主要介绍基于纠删码技术来实现数据冗余和容灾的技术原理。
图1 纠删码技术示意图
上图示例为一个由16个节点构成的对象存储集群，采用12+4的纠删码冗余方案。当业务准备写入一个对象时，对象存储将数据划分成12切片，加上4片校验数据，16个数据切片被平均写入每个节点上。如果应用发起读的请求，只需要从任意12个节点取出一个数据的切片即可合成原始的数据返回给应用。这样，任意四个节点上随机发生一块硬盘故障 者发生任意一个站点内所有四个节点故障都不影响已经存储的数据的完整性，对象存储可以继续响应业务发起的读请求。这种方案下，可用空间的利用率达到了75%。
相比较传统的磁盘阵列RAID6技术，如6+2方案，可用空间的利用率达到了75%，只能容忍两块硬盘同时故障。传统磁盘RAID技术有效节省空间但是高可用性一般。如果采用三副本的技术来实现冗余，可用空间的利用率只有30%，故障冗余能力较高，可以容忍三分之一节点同时故障。副本技术可用性高的代价是牺牲空间。
上述分析可见，采用纠删码技术的对象存储集群，提供的空间利用率不低于传统RAID，而故障冗余能力近似副本技术。当然主流对象存储采用SATA接口大容量而低速的磁盘介质，经过纠删码加工也存在一定开销，性能达不到传统块存储的水平。
对象存储的数据管理技术追求空间利用率高故障成熟能力高而损失一定性能，对象存储支持的访问接口又决定了它不支持数据被频繁修改的业务场景，综合来看，对象存储适合空间大性能要求不高不需要被频繁修改的海量非结构化数据存储的场景。
图2 对象存储容灾架构示意图
单套对象存储使用纠删码技术实现了高可用，按照金融行业业务连续性要求，非结构化数据业务也需要设计应对站点级灾难。上图给出了两种主流的对象存储容灾设计架构。
方案一，双站点复制容灾架构。
两套对象存储集群分别部署在一个数据中心，两个集群配置成复制关系。复制分两种 一种是单向的复制，只能由主站点对外提供服务，而且两个站点的用户是独立的，只有数据能够被复制到从站点。当主站点发生故障后，对象存储切换不是自动的需要人工干预完成。切换时应用会中断，需要根据从站点的用户信息更新应用的配置文件才能恢复业务。第二种复制关系两个站点为对等的关系，命名空间里的所有要素包括数据和用户都被复制到从站点。应用可以向任何一个站点发起访问的请求，写入的对象会被同步到对方站点。任何一个站点故障，应用不需要修改访问的配置因此不会中断。对象存储的“双活”架构完全不同于块存储的双活架构，不需要配置仲裁。
方案二，多站点全局纠删方案。
部署在不同物理站点的所有节点共同构成一个对象存储集群。应用发起的写请求被分片后分布到每个节点，这样物理上位于不同位置的节点在逻辑上按照一个集群的模式来冗余，任何一个站点故障后只要存活的节点数量满足要求就能够继续响应业务读请求。但是写请求维持不了原来的纠删码方案，个别厂商将以新的纠删码方案对待新写入的数据。这种方案要求是各站点之间的有足够的物理带宽要和良好稳定的线路质量。
金融行业内推荐双站点复制容灾架构。理由是每个站点都有一份完整的数据。在双站点的基础上还可以延伸出多站点相互复制的架构，适合规模较大的金融机构部署。
以某银行为例，2020年初立项了非结构化数据专用存储平台项目，立项的主要理由包括
第一，现有非结构化数据的运营管理痛点逐渐体现。现有产生非结构化数据的业务包括影像、事后监督、电话语音录音文件、双录系统视频文件及用于安全风险审计的日志，数据的规模是在线的数据约50TB，离线归档的数据约30TB，其中数据规模最大的为影像业务其文件的个数约为1.3亿个，数据的尺寸从4K到几兆不等。
维持上述体量数据的运行每年需要例行进行存储和备份设备扩容，硬件采购的 入和设备维保的费用逐年增加。另一个矛盾在于主要产生非结构化数据的业务通常对性能是不敏感的，因此造成成了块存储性能的浪费。而且为满足数据容灾要求在同城保留了第二份镜像，上述成本是double的。
运维管理的工作也愈发复杂。需要定期进行目录扩容，备份和清理保留时间超期的数据。而业务部门经常提出访问历史数据的请求，请求随机性较大，需要从备份中提取再恢复到生产环境，通常需要至少半天的时间才能准备好业务部门请求的历史数据。此类非结构化数据迁移到对象存储后可以“永久在线”。
兼顾到保障交易业务数据存储的需求，不得不对生产上非结构化数据的容量进行一定限制，这又和符合各类合规性要求的期望存在差距。例如按照监管机构的要求需至少保留三年的日志在线，只能频繁的归档至备份设备。
第二，行内新业务场景发展需要。为提供场景化交互式的服务，优化面向互联网业务的用户体验，银行准备建设一批新的业务，主要会生成多媒体格式的数据，建设论证的初期做了长远打算，规划相关业务直接开发支持S3协议的接口，使用专用对象存储存放。同时传统的业务厂商也推出了支持S3协议的软件版本并且具有成熟的实施案例，为银行推广对象存储提供一定可行性。
第三，重点考虑各类非结构化数据持久化和归档的需求场景。为了进一步减轻备份系统的压力，规划将超过一定期限访问较不频繁的数据备份归档在对象存储上。同时对象存储也可以作为大数据应用场景数据持久化的空间。
项目规划对象存储在银行主要应用场景是影像、日志、创新业务及归档。项目目标是从传统的块存储中剥离出非结构化数据，部署对象存储用于专用存储、管理和容灾，进一步理顺了行内存储管理的架构，节约总拥有成本，降低运维的复杂度。项目实施的过程中，逐步总结制定适合银行实际的非结构化数据管理的标准和规范，提升行内数据治理的能力。
确定了部署对象存储的目标，为提供更科学选型依据，制定对象存储产品POC测试的方案，各家厂商准备目标产品，执行测试方案。基于我们的实践经验，对象存储测试从基本功能，可用性、性能和运维管理四个方面进行全面考察，尤其需要关注差异化较大的方面。
第一，要求对象存储产品保留NFS接口，并且着重比较NFS实现方式和效果，以及支持接口的多样性。归纳了影像类、日志类、音视频类三个主要的非结构化数据业务群，计划全部迁移至对象存储。其中个别业务由于开发厂商原因不能改造成S3接口，需要在对象存储上为此类业务保留文件接口。另外银行已经部署 产了基于Hadoop的大数据分析平台，为此需要考虑对象存储应具备相应接口，可作为大数据持久化层。
参测厂商E | 其他参测厂商 | |
NFS实现方案 | 自带NFS接口 | 需要额外搭建NFS服务器 |
NFS和S3是否互联互通 | 互联互通 | 不互通 |
接口支持的多样性 | 支持HDFS | 支持其他接口类型有限 |
考虑到运维管理的简化，NFS实现方案尽可能简便易管理，优先考虑NFS接口和S3接口能够打通的方案，为未来业务改造S3接口提供基础。测试中一些厂商需额外的服务器来搭建实现NFS功能，建设成本和运维管理复杂度有所增加。NFS也是传统的文件系统，使用inode检索管理存储的文件。对象存储在存储数据时使用了key-value的数据库管理维护内部数据。两套接口完全没有关联，不能互联互通的话，对象存储只是作为下挂载NFS服务器里的空间在使用，所有数据检索的工作还是要靠NFS服务器完成，本质上没有消除文件系统管理海量数据的弊端。
第二，重点比较空间利用效率和故障冗余能力，优先考虑得盘率高且故障冗余能力强的产品。
表3 对象存储空间利用率及故障承受能力比较
参测厂商E | 参测厂商HW | 参测厂商HD | |
得盘率 | 12+4 75% | 8+2 80% | 20+6 77% |
随机硬盘同时故障数量 | 4 | 2 | 6 |
容忍节点的同时故障数 | 1 | 1 | 1个存储控制器 |
一个节点故障后服务能力 | 可以保证原方案纠删，读写不受影响 | 纠删的方案发生改变，读写不受影响 | |
节省空间技术 | 不支持 | 支持重删 | 支持重删 |
高可用性关心数据的安全以及服务能力。主流厂商的对象存储空间利用率比较接近，没有明显的差别，都达到了至少75% 80%的空间利用率。由于各厂商纠删算法和数据组织管理细节差异较大，故障冗余能力比较不同。纠删算法N+M，M的值越大冗余度越高。参测厂商HD允许随机发生硬盘同时故障的数量表现较好，但由于其存储节点为两控制器的中端存储，相比较其他厂家是分布式全对等的X86 服务器，HD厂商的产品有一定的局限。另外在发生一次故障后服务能力受影响的程度越低表现越好。参测厂商E的方案较为均衡。
第三，容灾能力是关键的考虑因素。银行业在非结构化数据容灾的思路选择上，可能两站点 多站点复制的方案接受度高，多站点全局纠删的架构适合对成本敏感多地经营网络延迟佳的非金融行业。
表4 对象存储容灾能力比较
参测厂商E | 参测厂商HW | 参测厂商HD | |
是否支持双活 | 支持 | 数据单向复制，且用户信息两站独立的 | 支持 |
NAS数据容灾方案 | 和S3数据一体容灾 | NAS额外搭建需因此NAS容灾另外部署 | NAS额外搭建需因此NAS容灾另外部署 |
参测厂商E和HD的容灾方案都支持数据从任何站点写入可以被复制到对方站点。对象存储的访问接口决定了可以充分利用现有的网络技术，即负载均衡和域名解析实现业务站点级高可用。业务访问对象存储需要配置到对象存储访问信息，最主要的是用户的信息及用Access key 和Securet Key, 参测厂商HW的复制是单向的，只有数据只能从主站点复制到从站点，而用户的在两个站点是独立的，这意味着主站点的存储故障，业务需要修改相关配置才能恢复。
第四，对象存储特有功能实现良好的，主要是指元数据管理的相关功能等。大部分参测厂家的产品都支持用户自定义元数据。
某银行采用Dell EMC公司的ECS EX300对象存储产品，充分适配行内实际环境和条件，结合一定自主开发，搭建完成了同城双活的对象存储集群。在同城两个数据中心，分别部署一套5节点的EX300，该产品自带的前端交换机对接行内万兆交换机，两站站点的万兆交换机通过波分复用设备联通构建数据复制链路。两个站点的对象存储不分主次，任意站点接受的写数据都可以同步到对方站点。另外至为关键的是，用户信息在一个站点创建被同步到另一个站点，业务访问两个站点的对象存储使用一套用户信息。应用访问两个站点的对象存储推荐的方案是采用F5 GTM的DNS智能解析在数据中心之间实现流量的负载和冗余。由于银行相关设备资源限制，同时考虑生产的F5 GTM在为行内业务流量承担负载的压力已经较大，而对象存储的数据流是带宽密集型的，因此银行规划访问对象存储网络独立于生产业务网，也不占用硬件负载的资源。我们自主搭建了基于Nginx负载均衡集群，虚拟机方式部署。访问对象存储的业务开发了专用的双IP 检测程序，当检测到生产对象存储无可用节点，自动切换至同城站点负载地址，不需要人工干预，业务无感知。
图3 行内对象存储架构
截止撰文时，业务适配对象存储的S3接口改造也完成并经过充分测试，完全满足要求。待年终结算后 产运行。银行影像业务保留了文件接口， 产时文件和S3的方式并存储，历史数据还在文件系统，新生成的数据在对象存储，后台迁移，更新数据库相应信息，标志存储的位置。
3.4.1 日常监控管理
ECS EX300对象存储产品(如下图所示)，与传统存储 者服务器产品相似，可以通过查看设备运行指示灯的方式监控设备的运行状态。主要查看设备、电源、磁盘和网卡的指示灯的状态，若绿色为正常，黄色 者红色为异常，可以联系设备维护商进行检查维修
除了硬件监控外，也可通过管理界面登录设备的方式，相对于传统存储设备，ECS设备管理简化很多。打开浏览器键入ECS登录地址，输入用户名/密码，即可登录ECS的管理界面，如下图所示，主要关注设备有无异常告警信息，节点和磁盘有无告警记录，请求的成功和失败信息，都可在登录界面直观展示，无需复杂的操作，进一步简化了日常监控运维管理。
3.4.2 与传统文件存储管理区别
对象存储对文件的使用方式与传统的文件型存储有很大的区别。传统的文件型存储需要建立文件路径，需要运维人员登录存储设备按照规则建立相应的目录，然后通过CIFS 者NFS挂载给主机才能使用。运维人员不仅要关注存储设备的资源使用情况，还要关注所有应用目录空间的使用情况，必要时进行相应的空间扩容。
而对象存储可以在任何地方 (位置透明) 并且不会绑定到特定的文件服务器、文件系统 者数据中心，对应用友好，通过扁平、全局统一的命名空间，允许分布式应用从任意地方进行就近数据访问，通过REST (HTTP-based) APIs 加速应用开发，应用可以在存储对象的时候自定义元数据，无需额外的数据库。自我管理的存储架构使得很容易进行扩展，无需创建LUN，无需创建文件系统，无需挂载共享目录，无需修改用完空间的应用，只要按需添加更多硬件就可以扩展到几百亿对象，具有近乎无限的扩展性，当新的对象存储进来后自动负载均衡，应用只需简单的创建、删除文件即可，无需关注更多的运维项。
3.4.3 权限管理
ECS存储支持多租户，可以很容易的实现访问隔离（租户间 。存储的桶（Bucket 可以按照不同的需求设置不同的功能和权限，桶是对象存储用于存储对象的容器，每一个对象必须存储在一个桶中。在规划对象存储的使用时候，需要提前考虑清楚租户、桶和应用的对应关系，不同的对应方式可以实现不同的目的。
默认情况下，只有对象的拥有者才能访问相应的对象，可以通过共享对象的方式给其它用户使用，使用者在可访问的期间内通过访问连接和对象的密钥访问，有别于传统的文件使用方式。
3.4.4 存储的空间管理
对象存储基于分布式架构设计，理论上其空间是无限扩展的，对于常规的应用用户，只需要关注对象文件的使用即可，即数据的读取和写入，无需关注数据的存储空间增长，也无需要做传统数据存储对应的索引数据库的管理，简化了日常使用。
存储管理人员除监控存储设备的运行状态外，仅需要关注对象存储池空间的管理即可。需要特别注意的是，按照当前ECS的管理策略，当存储池空间达到90%时，将不再接受数据的写入操作，变成只读状态，仅支持数据的读操作。这需要存储的维护人员密切关注存储池的数据增长，调整常规的监控阈值，与之相匹配，避免存储数据不能写入事件的发生。同时，为满足存储管理人员的日常管理需求，ECS存储针对存储池空间使用可以配置三种不同的告警级别，分别是警示、告警和严重级别。每种级别可以根据使用实际情况做一些个性化的调整，例如，警示级别，支持设置35%、40% 者不告警，当设置40%时，一旦存储池剩余空间少于40%将会触发告警。
3.4.5 数据的备份与归档
对象存储自身做了一定的数据保护设计，可以根据自己的需要确定是否需要继续进行数据保护。除了前文讲的基于纠删码技术来实现数据冗余外，对象存储做了相应的预防逻辑错误的设计，对象存储支持数据多版本写入，每次的数据写入均会产生一个新的数据版本。使用人可以根据需要通过API将之前的数据版本恢复为最新版本，删除数据的时候并不会真正的删除数据，仅仅是是的数据通过API访问不可用，支持通过删除数据的版本ID来进行数据删除才能够真正的删除数据。
对象存储支持数据归档处理，可以根据数据管理情况设置与之相匹配的数据归档测试，满足数据分类分级存储的需求，选择使用对象存储时，可以提前考虑。
总结基于Dell EMC ECS的对象存储实践历程，有几点心得供分享。
第一，部署对象存储要规划在前。首要的是制定适合自身实际的非结构化数据管理规范，哪些数据可以被认定为非结构化数据，迁移对象存储的门槛是是什么，要提前想清楚这些问题。要充分调研生产环境存在的各类数据格式及体量，盘点好存量。要有前瞻性，充分预见未来数年行内业务发展的方向及预估未来数据的形式和规模。只有这样，才能做出科学的决策。
第二，运维对象存储要转变运营传统存储的思路，树立服务业务需要，面向开发的理念。对象存储使用Restful http的访问接口，直接为应用调用，抽离过去连接应用和存储的中间层，要用对象存储需要系统和应用 ，使开发人员充分理解基于S3 开发相关知识。
第三，对象存储简化日常管理，可加速业务转型，对象存储在支持数据增长，多站点容灾和传统的数据备份具有诸多的优势，解决很多传统数据运维的痛点，很好适应当前金融业信息系统多站点容灾、数据多样化和爆炸式增长的需求。
点击文末 ，可以到原文下留言交流
觉得本文有用，请转发 点击“在看”，让更多同行看到
欢迎关注社区 “存储”技术主题 ，将会不断更新优质 、文章。地址 https://www..com/Topic/179
长按二维码关注
*本 所发布内容仅代表作者观点，不代表社区立场
Powered by 小羊羔外链网 8.3.12
©2015 - 2024 小羊羔外链网
您的IP:13.59.82.167,2024-04-25 06:58:29,Processed in 0.05366 second(s).
