背景
企业不断前进发展内在需求，促使企业管理不断主动变革，应对挑战。同时，随着企业的发展，不断产生的非结构化数据（非结构化数据，包含对象存储和文件存储）规模也越来越庞大。降低成本和提升效率的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+对象存储。
架构设计的通用考虑规则：
对象存储系统的每个逻辑实体必须要要有冗余，且要支持横向性能扩展，并对客户端透明，规避单点风险；
对使用对象存储的生产应用运行状态进行监控，监控方法应尽量仿真用户的实际使用方式；
当对象存储系统的某个部分发生异常的时候，能快速隔离或通过重启来恢复功能模块的正常使用；
企业内网与外部互联网对对象存储的访问，应该做好数据隔离和权限隔离。对于互联网上传数据，企业内网下载的场景，应该做好防病毒扫描。对于企业内网上传数据，互联网下载数据的场景，应该通过权限控制或者API控制的方式严格阻止。对于不同应用之间共享对象存储数据的场景，可以选择全量授权和bucket授权两种方式；
针对不同的网络安全区域，提供不同的对象存储接口以实现对应的权限控制；
是否有数据加密的需求；
是否有容灾和计费的需求；
并发 吞吐量 可用率等方面的需求；
架构设计中的两个小例子
ceph存储中 client 跟 OSD的 TCP交互很多，如果没有提前放大TCP端口范文，会导致TCP连接端口耗尽造成故障
ceph存储中，应该将OS的 openfile参数调整为最大，否则会导致OSD进程down。
POC测试的部分结果与数据
从下面部分的测试结果来看，在网络带宽受限的条件下，对象存储的写响应时间在100ms 左右，读响应时间也在20ms左右。