1 现状及需求
随着业务规模的不断发展，监管力度的不断加强，保护消费者法的不断完善，应用系统每时每刻产生日志数据、业务影像数据、历史数据都在海量增长，都有可能够成为争议交易的佐证证据，且这些日志种类繁杂，格式多样，散落在生产系统的各个角落，往往只有在出现问题时才会到海量日志中去查找和分析，这些信息可以对系统的优化、运维以及运营带来重要的决策参考，所以建设一套可供上述数据永久存放的存储，并在相当长的一段时间内维护得当，随时能够满足查询需求，已经变得尤为重要。
银行的上述非结构化数据种类繁多，用途各有不同，虽然制定了大部分数据的清理策略，但是在归档后，因为各种原因查询缓慢，人力投入过大，更加不能得到充分的分析及应用。究其原因有两点，一是日志格式多样且繁杂散乱，日志的分析存在一些难点和问题；二是日志数据量巨大，传统存储架构无法支撑海量数据。
尤其对于数百TB的日志类数据，庞大的数据量不仅增大了运维人员的监管和分析的难度，使得日志类数据的价值更加难以挖掘，而且传统的数据存储方式已经不能满足海量交易类日志数据对于安全性、可靠性和扩展性的要求，急需一个合适的统一历史数据管理与存储方案，用作数据的集中管理、辅助监控和分析以及交易类历史日志数据长期归档存放。
存储不仅要满足现在应用的需求，同时也要为未来数据增长提供良好的可扩展性，随着银行业务的数据量爆发式的增长，如票据影像、日志数据、数据库归档数据等，同时生成部分应用对数据的要求全天候访问，现有的存储基础架构显得有些力不从心，系统管理复杂、运营成本不断上升，存储设施面临着多重挑战。
私有云的存储方案在为未来业务发展提高强大的可扩展能力和服务能力，同时能够有效提升海量数据的可管理性、可靠性以及可用性。通过增加集群规模，容量和性能能够同步提升，能够很好地满足银行业务发展的需求。
2 在上述场景中传统存储的缺陷
1) 扩展能力不足：不能进行灵活的扩展以满足快速变化的业务需求，缺乏可扩展性或大规模文件处理能力，且容易在管理不善的情况下造成数据孤岛，查询起来非常繁杂。
2) 数据可靠性：存储数据的来源越来越多样化，对数据可靠性提出更高的要求，在满足数据可靠性的同时，还需要平衡硬盘利用率，避免牺牲大量的存储空间（原始数据几倍的存储空间）来满足数据可靠性要求，传统存储一直使用一个资源池，不利于长期保存。
3)系统性能瓶颈：传统集中式存储Scale-up架构的性能无法线性增长，面临海量数据的高带宽要求时，往往无法快速响应应用的读写请求，尤其是大文件和海量小碎文件读写。
4)管理维护难度大：随着应用不断发展，现有的数据规模已经超出原有平台管理的峰值，存储设备的增多带来维护成本居高不下，多套存储系统空间不能共用，管理复杂，需要多个IT管理人员维护多套不同的存储设备和网络，总体成本急剧上升。
3云上存储具备的能力
1)线性扩展能力： 系统应具有良好的拓展能力，最大可扩展容量应能达到数十PB以上，同时性能随容量的提升线性增加，确保整套系统随容量增长不出现性能瓶颈，整套系统的扩展能力应能满足未来3-5年数据增长和长期归档的需求。
2)高可靠性： 系统应保证有充分的冗余，在部分硬盘或节点损坏时系统能够自动恢复而不影响业务运行，同时应保证系统在7*24的高负荷环境中依然有良好的安全可靠性。
3)易维护性： 系统的运维管理应尽量简单，采用可视化图形界面对整套系统进行监控维护，一旦发生故障应能主动告警，并迅速定位故障点，硬件部署安装也应简便，方便进行系统扩容和节点替换。
4)提供的存储服务： 从日志检索这个出发点，经过时间的积累，必然会走向分析、告警、预测，而从需求反推支撑功能的实现，平台必须在如下方面进行考虑：能够准确查询日志，支持便捷使用，可以真正用起来，除满足日常归档存储的功能外，应该具备对象存储功能，对外提供对象存储接口，一般对象存储服务提供了2套标准接口，分别符合Amazon S3和Openstack Swift规范；从影像数据存储需求出发，也可以通过对象存储完成存储与查询，但是因为要变更应用接口，不适用于所有应用，所以仍然需要提供NAS存储服务，在访问安全方面可通过设置NFS、CIFS、FTP及私有客户端四种共享的权限来限制访问的用户；从历史结构化数据存储以及备份介质的需求出发，块数据功能可以满足此种服务需求。从存储系统的业务供给能力角度看，不同存储系统可以提供块存储、对象存储、文件存储等不同类型的存储服务。假如用户有多种需求，就需要购买不同类型的存储系统。分布式融合存储系统可提供块、对象、文件与大数据等多种不同的存储接口，提供多种不同的存储服务，从而达到统一存储的特性，降低多种存储系统带来的运维复杂度，提高存储资源利用率，节省机房空间。
4 日常维护
云存储的日常维护，必须考虑建设阶段的策略选择，例如可靠性、性能、扩展能力等，只有在建设阶段选择了适当的策略，日常运维中才能做到从容不迫。
1) 高可靠
对于大容量的私有云存储，纠删码技术和多副本相比更加适用，纠删码技术以同样的初始容量存储更多的数据,磁盘利用率更高，从而大大降低了成本。举例来说，3副本的利用率是1/3；而k+m纠删码的利用率是k/（k+m），如8+2的利用率是8/10。
2)高性能
面对历史数据归档场景的云上存储，对使用者来说，存储系统的性能体现在两个方面：一个是从客户端角度看，客户端可以从系统获得的性能；一个是从存储集群的角度看，存储集群的供给能力。
从客户端角度看，集群中的文件或LUN会根据特有算法伪随机地分散在集群的所有磁盘。这个分布是通过集群自动完成，无需手动配置。由于每个文件或LUN可以使用整个集群的磁盘性能，因此整个集群能够提供更高的性能。在云上存储集群中，通过分析将要存放的文件类型，调整存储块的大小，也是非常有必要的，默认存储对象的大小是4M（可配置），比如一个1GB大小的文件或LUN，会被划分成256个对象，这些对象分散在不同的OSD上。这样在读写文件时，就会充分利用集群的整体性能，提升IOPS和吞吐率。
存储集群的性能取决于两方面：一方面是单节点的能力，另一方面是系统的扩展能力。如前所述，云上存储系统的性能可以随节点的规模而线性扩展。对于单节点的能力，云上存储在系统设计和硬件配置方便实现了足够的灵活性，从而可以表现出良好的性能。
对于历史数据查阅的频繁度，可以简单区分一下所使用的硬盘资源池。对传统HDD来说，受寻道能力的限制，单盘的随机读写能力一般不超过200个IOPS。SSD的出现，使得在IOPS上的能力相比于HDD有了成倍的提升，甚至是数量级的提升。在SSD+HDD混合组网模式下，云上存储系统既可以将SSD作为缓存使用，也可以将SSD和HDD放到不同的存储池做分层存储使用。在此情况下可以发挥SSD 的IOPS和带宽的优势，又可以发挥HDD的容量和价格优势。
3)高扩展
集群的线性扩展能力，主要体现在两个方面：一个是集群部署规模可以线性扩展，另一个方面，随集群规模的扩展，其性能要能够线性或近似线性扩展，随着服务器使用年限的增长，不断将重要历史数据迁移到新的资源池也是一个较为重要的需求。
在规模上，传统存储之所以在扩展能力上受限，一个很重要的原因就是一般其采用集中式控制，并且在控制节点存储大量的元数据信息，从而使控制节点容易成为系统的瓶颈。对于云上系统， 客户端节点通过特有算法可以直接计算出数据的存储位置，从而对OSD进行直接读写，完全是分布式并行的；而其元数据，也就是集群视图，是轻量级数据，而且其更新的频率较低。这种架构就在理论上保证了云上存储具备线性扩展能力。
在性能上，根据集群的分布式架构，客户端的读写数据最终会被打散，均匀分布到各OSD上，从而集群整体的吞吐率是各节点能力的总和，即集群的性能随节点数量的增加而线性增加。
5 通过云上存储提供的功能简化运维操作
云上存储为了简化管理运维应该具备大量自动化运维工具：
1)集群快速部署及增减节点
包括批量部署、单节点增减、单磁盘增减等。从部署上来说云上存储系统可以根据用户需求灵活地部署Monitor节点和Client节点。一方面，这些节点既可以部署在单独的物理服务器上，也可以部署在和OSD相同的物理节点上。另一方面，Monitor和Client的节点可以根据用户的需求灵活地调整。比如为了可靠性保证，至少需要部署3个Monitor节点；在增删存储介质，或存储介质发生故障时，系统会及时进行检测。比如，在磁盘发生故障时，分布式融合存储会利用损坏数据在其他存储体上的副本进行复制，并将复制的数据保存在健康的存储体上；在增加磁盘时，同样会把其他存储体的数据安排容量比例重新分布到新磁盘，使集群的数据达到均衡。在上述过程中，虽然完全不需要人工干预，但是仍然需要依靠人工巡检保证系统运转状态正常。
2)系统监控报警
发生故障时能快速界定问题、排查故障，除系统本身的监控外，因为存储分布式架构，最好额外增加针对硬件级别的监控。
3)自定义分布策略
允许定制数据分布策略，方便地进行冷热数据分离、故障域隔离，以及对数据存储位置进行灵活选择。比如在选用副本策略时，用户可能希望不同数据副本存储在不同机架上面的主机上；或者主副本存储在某个机架的主机上，其它副本存储在另外机架的主机上；此类需求可以灵活调整故障域和保护域策略，已满足需求。
4)重构自动Qos
在系统平衡数据（例如系统扩容或者存储节点、磁盘发生故障）的过程中，为保证用户IO，云上存储系统支持IO优先级控制和Qos保证能力。我们知道，在系统扩容或者存储节点、磁盘故障过程中，为保证数据的可靠性，系统会自动进行数据平衡。为了尽快完成数据平衡，往往会占满每个存储节点的带宽和IO能力，这样做的好处是会使平衡时间最短，坏处是此时前端用户的IO请求会得不到满足。在日常业务系统正常运行的场景下，我们是无法接受这种状况的。为此，云上存储系统实现了IO优先级和Qos控制机制，可以根据我们日常的网络流量和后端存储网络流量进行控制，保证一定比例IO得到满足。