金融集团对象存储需求分析和架构设计

大型金融集团对象存储需求分析和架构设计背景企业不断前进发展内在需求，促使企业管理不断主动变革，应对挑战。同时，随着企业的发展，不断产生的非结构化数据（非结构化数据，包含对象存储和文件存储）规模也越来越庞大。降低成本和提升效率的KPI需求，促使管理层不断寻找新的解决方案，创造新的价值，应对新的挑战。随着AWS的快速发展，对象存储影响力随着aws s3的市场份额的扩张，而不断增强。公司从2013年开始追踪研究对象存储解决方案，对比了E厂商H厂商 D厂商等解决方案，同时也开展了基于openstack框架下的Swift对象存储研究，技术选型方案汇报到管理层后，从技术先进性，企业发展战略，社区热度，稳定性，成本，发展路线图等方面综合考量，评估，在2014年初做出了使用ceph作为对象存储开发技术原型的决定。2014年11月自研对象存储正式上线，对象存储在公司的应用规模得到快速发展，如今已经达到了数十PB的规模，分布在数个不同地域的数据中心。在自己研发的对象存储占据主导地位同时，还有H厂商和I厂商的对象存储应用在不同场景中，其中I厂商的容量快速扩张，D厂商的对象存储在竞争中败下阵来，逐渐被淘汰。对象存储发展的方案建议企业发展的不同阶段，不同的战略目标，面临的IT管理的不同挑战，决定企业会选择哪种存储发展路线图，决定企业是否使用对象存储，如何使用对象存储。这是一个因地制宜的决策过程。很难有一个统一的对象存储发展方案来满足所有的企业。但是有如下的因素，我觉得是在所有的对象存储方案中都应该考虑的：1. 准确的需求分析需求分析是最重要的基础，如果没有需求分析，成本和收益分析就变成了无本之木，无源之水，后续的方案设计就变成了空中楼阁2. 企业发展战略和目标，IT管理战略和目标技术发展路线和方案，永远要服务于IT管理目标，服务于企业战略发展。这样才能取得多赢3. 对象存储的成本和可用性之间,评估并设置一个恰当的平衡点不谈成本和收益的架构设计没有实际的意义。过高的可用性浪费了企业成本，过低的可用性却不能满足业务的需求。这个平衡点很难把握。对象存储的选型评估当前对象存储主要应用在: 大数据分析、备份、归档、内容分发、云存储5个场景中。针对具体的对象存储应用场景，可以针对如下的指标设置不同的打分权重，比如用在公有云场景中，租户管理能力就是一个加大权重的考核点。在高可用方面，是否支持跨地域数据中心部署存储集群是一个重要的考核点。当前市场上有很多对象存储解决方案，我们挑一些具有代表性的产品来看，其中 I厂商的对象存储，在跨数据中心部署存储集群方面的能力比较突出，纠删码的配置也比较灵活。同时支持软件部署和软硬一体部署两种方式。H厂商，支持元数据检索功能。另外具备压缩去重功能。还在删除数据的时候具备数据粉碎功能，增强了安全级别。只支持软硬一体的部署方式。N厂商，支持跨数据中心部署全局纠删，支持元数据检索。存储空间使用效率稍低。ceph对象存储，社区很热的开源项目，也具有很大的吸引力。面对单一的具体的需求场景，就需要对比更具体的技术细节，如面对备份场景，bucket的创建数量，是否支持版本，支持版本数量有无限制？读写吞吐多大？而面对多应用需求场景下，各种具体的技术细节都要考虑到，比如公有云场景：还有着重考虑多租户管理的能力。文件存储和对象存储的差异非结构化数据，包含对象存储和文件存储，那么在不同的场景中如何选择用对象存储还是文件存储呢？从技术角度，我们要从这两种存储的本质来看，对象存储访问接口基于http协议，这种协议显然比NFS和CIFS协议更适用于互联网。整个互联网就是以http协议作为基石的。因此对于互联网类开发应用，如IOS安卓APP之类的手机应用，直接调用基于http的接口显然更方便。如果使用NAS存储，还需要应用程序将文件存储封装成http接口的API提供给其他程序模块调用。应用由文件存储转对象存储的理由在使用对象存储之前，企业的非结构化数据都是存放在NAS存储设备上，主要以NFS和CIFS的方式对用户提供服务。在使用文件存储的过程中，开发同事眼中的NAS有如下的问题：1.要走两天以上的流程才能申请一个NAS卷挂载到指定的服务器上2.一个NAS卷上读写过于密集会不会有性能问题呢？每次查询都要读取一个XML文件，而且要频繁更新3.我们的软件系统是按照业务系列分套隔离的，NAS设备要不要分成多套进行物理隔离4.基于NAS存储设备的高可用架构设计复杂，具体某场景架构描述如下1）. 主备NAS卷来解决数据丢失问题。2）. 主备分别使用不通硬件厂商设备、并部署在不通的机房来隔离硬件影响。3）. 应用分成4套来隔离业务影响，存储也分成4套保证能真正的完全隔离。4）. 实时灾备到张江，保证能够应对灾难。5）. 多网络区域 多应用实例的复杂设计基于上面的问题，开发同事期望存储设备能够满足如下的要求：1.应用开发不需要考虑存储的架构设计；2.应用开发不需要考虑存储的容量管理；3.存储设备过保替换对应用和影响降低到最小；4.存储容量可以弹性，支持高吞吐，高可用且稳定，数据安全，简单易用；不会随着容量的成倍增长，而引发存储运维成本的成倍增长；5.专注应用开发运维本身，无需考虑存储；6.简化存储的运维管理工作，降低运维管理成本。基于上面的理由，开发同事做出了由对象存储替换文件存储的应用架构调整决定。以客观的技术视角来看，两天时间申请一个NAS卷，是因为IT管理和人力投入综合决定的，如果用自动化来处理只需要30秒钟。NAS卷的响应时间是对象存储的10分之一，在应对随机IO的场景中比对象存储更出色。至于存储容量的弹性管理，随时能扩容的前提是存储资源池中提前储备了物理资源。一定程度上增加了成本。存储设备用满5年，需要替换为新的NAS存储设备，在不同品牌NAS存储设备之间数据迁移完成后，应用需要读取新存储设备上面的nas卷，则必须在操作系统上停止进程对NAS卷的访问，才能umount旧的NAS卷，mount新存储上的NAS卷程。这个新旧NAS卷切换的过程中，尚不能完全的做到在线的切换，因此需要申请一个变更时间窗口，而对运营 开发 业务沟通和申请变更窗口成为一个比较花时间的工作。对象存储的分布式架构，可以在线完成设备过保替换。再举一个场景应用的例子保险行业有一个比较特殊的应用场景，电话录音，每一个通过电话销售出的保险都需要录音存档，按照法规监管的需求保留一定的年限。原来这些数据都是长期保留到磁带上。随着监管抽检录音时效的要求，受限于磁带从介质保管室放入磁带库需要人工操作，短时间内恢复数百通不连续录音的时效不能满足监管的需求。如果这些数据不放置在离线磁带上，而是放置在对象存储上面，对录音的查询和调阅时效，会提升很多！某大型金融集团对象存储架构设计系统重要性定义在金融行业中，针对具体的场景分析，我们可以按照如下的几个点，来划分系统的重要性，区分不同的场景和保障等级。 针对A类系统，我们可以提出更高的可用性需求；针对C类系统，我们可以降低可用性需求从而降低成本。对象存储架构发展路线图规划与制定：要制定自己的对象存储发展路线图，包括自研对象存储,开源对象存储产品应用与外购商品化对象存储三种技术路线，三种技术路线又可以以不同的比例组合起来。在制定对象存储发展路线图的过程中，不同的企业面对的具体挑战不同，制定的路线图也会有差异。但是我觉得如下的考量因素是共用的。1. 是否必须对象存储才能满足需求，是否有替代方案；2. 成本因素在决策中占多大的比重；3. 技术先进性在决策中占多大的比重；4. 企业战略发展目标在决策中占多大的比重；5. 组织管理目标在决策中占多大的比重；机房规划设计1.要根据业务的重要程度决定对象存储的服务承诺，对象存储服务的承诺，一定程度上依赖机房的高可用，所以要根据成本和需求等因素综合考量选择不同级别的机房；2. 要考虑主要客户群所处的地理位置。如果主要客户在东部沿海，那么在上海选用一个数据中心会提供更快的响应速度。网络规划设计对于对象存储使用的网络，分成三个基本的网络区域，管理网络，用于对象存储设备的底层管理，主要考虑物理隔离。内部数据传输网络，用户存储节点之间用来交互数据，要求具备充分的带宽。对互联网提供服务网络，这个网段用来响应互联网http请求。服务器规划设计如果是基于X86架构的服务器构建ceph对象存储，需要考虑CPU数量和频率 内存的数量和频率，以及硬盘的数量，容量，和类型。 如下是一种实际应用的典型配置：Intel Xeon E5-2630(v3) 2.40GHz 2CPU 16core 88G(DDR4-2133)内存2400G（SSD，S3710，6Gb，SATA2.5）+124TB(SATA 3.5，7.2K)2Intel万兆双口网卡(X540芯片，电口)其中的硬盘的数量和大小就是充分考虑了，节点故障和硬盘故障的恢复时效。负载均衡的规划设计DNS 域名解析，可以解析到不同的IP地址上，采用DNS轮训的策略，一定程度上能够实现负载均衡，但是DNS不具备故障探测的功能，当一个IP故障的时候，DNS仍旧会分发请求，造成对象存储的访问请求失败。DNS+F5的方式，可以比较完美的解决负载均衡的问题。但是F5作为世界知名负载均衡厂商，成本是企业需要考虑的一个点。DNS+LVS 可以一定程度上实现负载均衡，同时解决了DNS不具备故障检测的功能。在转发模式一般选择性能最高的DR模式，要注意的是LVS DR模式不能跨网段。DNS+LVS+keepalived 方案，用来规避LVS发生故障的缺陷，实现LVS的高可用。DNS+ LVS+keepalived+nginx 方案用， nginx用来做分流-一种负载均衡的另一个名字，主要可以根据IP URL权重 响应时间四个维度来设置参数进行负载均衡。我们还可以用cdn进行内容加速，因此最终采用的对象存储架构为CDN+DNS+ keepalived+LVS+nginx+对象存储。架构设计的通用考虑规则：1. 对象存储系统的每个逻辑实体必须要要有冗余，且要支持横向性能扩展，并对客户端透明，规避单点风险；2. 对使用对象存储的生产应用运行状态进行监控，监控方法应尽量仿真用户的实际使用方式；3. 当对象存储系统的某个部分发生异常的时候，能快速隔离或通过重启来恢复功能模块的正常使用；4. 企业内网与外部互联网对对象存储的访问，应该做好数据隔离和权限隔离。对于互联网上传数据，企业内网下载的场景，应该做好防病毒扫描。对于企业内网上传数据，互联网下载数据的场景，应该通过权限控制或者API控制的方式严格阻止。对于不同应用之间共享对象存储数据的场景，可以选择全量授权和bucket授权两种方式；5. 针对不同的网络安全区域，提供不同的对象存储接口以实现对应的权限控制；6. 是否有数据加密的需求；7. 是否有容灾和计费的需求；8. 并发 吞吐量 可用率等方面的需求；架构设计中的两个小例子1. ceph存储中 client 跟 OSD的 TCP交互很多，如果没有提前放大TCP端口范文，会导致TCP连接端口耗尽造成故障2. ceph存储中，应该将OS的 openfile参数调整为最大，否则会导致OSD进程down。POC测试的部分结果与数据从下面部分的测试结果来看，在网络带宽受限的条件下，对象存储的写响应时间在100ms 左右，读响应时间也在20ms左右。-end-12