搜索
11BC-oNest对象存储（BC-oNest）入门中移（苏州）软件技术有限公司云计算产品部2017.0922课程体系集群测试集群运维集群部署架构与运行机制背景与概念33课程内容–基础篇章节内容1对象存储技术介绍对象存储基本概念，BC-oNest产品介绍2Ceph简介Ceph项目介绍，总体架构，网络架构3Ceph运行机制–RADOS基本概念，副本/纠删码，PG4Ceph运行机制–CRUSH算法，bucket，权重，规则编写，Map设计5初级部署-方案设计与部署操作简单部署规划，基本环境配置，ceph-deploy部署8常见测试工具及基础性能与功能测试测试用例设计，测试工具使用，数据监控分析10基本运维操作获取宏观集群信息，启停服务，查询服务状态，获取基本的日志信息12多数据中心架构与原理，简单操作13BC-oNestBlueprint未来BC-oNest的发展规划与发展方向401对象存储技术介绍存储现状与存储体系对象的概念对象存储与文件存储对比对象存储定位5存储体系结构层次•高性能，大多数数据库使用块存储设备•应用于关键业务和数据极度敏感业务，常见于高端存储块存储•丰富的共享接口，存储非结构化数据•应用于多种场景，尤其是依赖NFS/CIFS/POSIX接口的系统文件存储•水平高扩展性，存储非结构化数据，操作及管理简单•应用于多种场景，比如网盘云存储，备份，归档等对象存储应用程序文件系统接口文件系统层磁盘驱动应用程序文件系统接口文件系统层磁盘驱动应用程序文件系统接口文件系统层磁盘驱动内部网局域网万维网块接口块设备文件接口服务器对象接口x86/ARM块存储文件存储对象存储6什么是对象定制元数据•分类：宠物•分享策略：不分享•存储时间：1年系统元数据文件名：dog.jpg创建时间：2016.10.10文件定制元数据系统元数据文件文件+元数据=对象7系统架构硬件层引擎层服务层接口层存储管理RAID/HBA卡管理SAS/SATA/SSD兼容业务网(10GE/IB)集群故障自愈并行一致性检查数据哈希分布数据强一致性集群状态管理智能恢复硬件感知原生接口存储池隔离资源监控自动化部署在线升级磁盘点灯监控告警日志管理告警管理用户管理信息统计S3接口磁盘错误检测/管理x86通用服务器数据平衡硬件加速自适应配置数据迁移Swift接口管理接口存储网(10GE/IB)文件接口8管理系统集群概况存储池数量节点/磁盘数量风险/告警监控9产品应用场景BC-oNest拥有水平扩展、高可靠、高性能等特点：•应用于视频、图片的存储，结合CDN加速，提升用户体验；•在备份、文件存储和归档等领域应用前景广阔；•逐渐替代传统网络存储系统(NAS)；资源托管静态网站托管图片、视频存储视频/图片转码归档存储内容分发替代传统NAS作为备份系统为虚机及卷提供备份存储CDN后台存储系统在线视音频及图片极速转码视频点直播、存储与下载1002Ceph简介Ceph缘起Ceph总体架构集群组件集群网络构成11Ceph是加州大学SantaCruz分校的SageA.Weil专为博士论文设计的新一代自由软件分布式文件系统。自2007年毕业之后，Sage开始全职投入到Ceph开发之中。LuminousCeph缘起12版本更迭13总体架构14RGWOSDMONMGRMDSRESTMonitorMONManagerMGR提供POSIX文件接口MDSObjectStorageDeviceOSD提供S3、Swift接口RADOSGateway提供HTTPRestfulAPI接口CEPH-REST-API集群组件15集群组网一个集群通常有三套网络：-前端业务网-后端存储网-管理网16生产环境组网1703Ceph对象存储运行机制RADOSCRUSH1803-1RADOS基本概念副本与纠删码PlacementGroupClusterMapScrubbing1919RADOSaReliable,AutonomicDistributedObjectStoreStrongConsistencyReplicationPetabyteScaleOSD+MONRecoveryFailureDetectionPartofCeph几个词需要理解：RADOS，OSD，MON，PG，CRUSH2020RADOSaReliable,AutonomicDistributedObjectStoreOSD之间，OSD与Monitor之间均存在心跳2121副本策略2222副本策略当前Ceph使用第一种方式分发数据，日志写入完成即可返回ACK读取只从主OSD读取2323纠删码策略K+MKM2424纠删码策略2525纠删码策略2626纠删码策略2727纠删码策略2828纠删码策略纠删码策略ABCDEFGHIJKLMNOPOSD21（主OSD）OSD42OSD1OSD74OSD43OSD56ABIJ………………编码（4+2）CDKL…………EFMN…………GHOP…………YXZY…………STKQ…………对象名分片2对象名分片3对象名分片4对象名分片5对象名分片6对象名对象内容对象名分片1主OSD计算分片并分发3030纠删码策略OSD21（主OSD）OSD42OSD1OSD74OSD43OSD56ABIJ…………解码（4+2）CDKL…………EFMN…………GHOP…………YXZY…………STKQ…………对象名分片2对象名分片3对象名分片4对象名分片5对象名分片6对象名分片1客户端主OSD合并分片并解码返回3131纠删码策略默认Jerasure（Reed-Solomon|CauchyReed-Solomon）当前推荐IntelISA-L状态：in/out，up/downPG包括actingset，upset-actingset：包含一个PG内所有副本数据的集合-upset：实际处理请求的集合-绝大部分情况下两者一致，不一致的情况通常是在恢复，或是其它问题3434PlacementGroupPG状态：-creating：PG增加时才会出现，如创建存储池，PG分裂。如果卡在这一阶段，请检查当前的CRUSHMap是否能够满足你的CRUSHRule-peering：PG内的OSD还未就PG状态达成一致；-active：PG内的数据可以读写；-clean：PG内的OSD成功peer，并且PG内没有未就位的数据；active+clean才是正常的状态！3535PlacementGroupPG状态：-degraded：降级-例1，【主OSD】接收到数据，但没接收到【从OSD】返回ACK；-例2，PG内的一个OSDdown掉，则整个PG会被标为active+degraded，直到该OSD回来，或者该OSD超时后OUT，PG重组；-例3：Ceph在PG内找不到理应在该PG内的数据，则该PG会被降级（degraded），但该PG内其它数据依然可用，直到问题解决；这状态常见！3636PlacementGroupPG状态：-recovering：PG内的数据正在恢复；-back-filling：PG内的数据正在回填；-backfill_wait：PG内的数据正等待回填；-backfill_too_full：集群太满，无法回填；如果长期无法回填，PG有可能会被标记为incomplete；上述都反映恢复状态！3737PlacementGroupPG状态：-remapped：PG的actingset已经变化，但新的OSD还没做好接受请求的准备，这时需要旧的OSD继续接受请求。当新的OSD可用，两个set相同，该状态会消失；-stale：PG内的主OSD向monitor报告PGactingset失败，或是从OSD报告主OSDdown，则PG会被标记为stale；stale意味着通信失败，建议检查网络状况3838PlacementGroupPG状态：-misplaced：PG回填时，可能会使用临时OSD，由于这时临时的而不是正常的，所以会被标记为misplaced。或者说，所有副本都确实存在，但一个或多个副本没有再应该在的OSD上；pg1.5:up=acting:[0,1,2]addosd3pg1.5:up:[0,3,1]acting:[0,1,2][0,1,2]是一个临时mapping，所以两个set不相等。但由于[0,1,2]是确实存在的三副本，故而状态是misplaced，而不是degraded3939PlacementGroupPG状态：-incomplete：PG不完整，通信失败，没有足够的OSD去恢复数据。pg1.5:up=acting:[1,2,3]pg1.5:up:[1,4,3]acting:[1,2,3]【加入4，去掉2，回填】此时，如果OSD1,2,3全部挂了……4可能还没有完全回填，那么数据不完整，或者说没有足够的OSD去恢复数据。此时，PG状态会被标记为incomplete4040ClusterMapMonitor维护ClusterMap：-规定了哪个OSD在集群里，及集群中数据要如何分布；-Map版本永远不会倒退；-Map更新只发差异图（增量更新）；-PG基于clustermap分配到OSD上（CRUSH）；4141ScrubbingScrub，DeepScrub：-Scrubbing的作用是PG内的数据一致性检查；-Scrub只检查PG内的元数据，主要用于检查bug及文件系统错误；-DeepScrub则会按位去校验实际对象数据；通常每天一次Scrub，每周一次DeepScrub4203-2CRUSHCRUSH算法BucketType“Weights”FailureDomainCRUSHMap设计43CRUSHControlledReplicationUnderScalableHashing44independancefirstnCRUSH两种PG变化策略45BucketType这里的bucket，和对象存储的bucket概念并不一致！在CRUSHMap里，只有OSD是和物理设备对应的46BucketTypeStrawBuckets:𝒄𝒄𝒓𝒓,𝒙𝒙=𝒎𝒎𝒎𝒎𝒙𝒙𝒊𝒊(𝒇𝒇𝒘𝒘𝒊𝒊,𝒉𝒉𝒎𝒎𝒉𝒉𝒉𝒉𝒙𝒙,𝒓𝒓,𝒊𝒊)𝑟𝑟为副本数，𝑥𝑥为输入，𝑓𝑓𝑤𝑤𝑖𝑖则将straw的长度基于权重进行缩放特点：这种类型让bucket所包含的所有item公平的竞争(不像list和tree一样需要遍历)。每一个bucket都会被分配到一个签，最长的签最有可能胜出。签的长度由CRUSH输入x,副本数r，itemi决定，并被因子f(Wi)（与权重有关，保证权重越高越容易胜出）伸缩，即：length=f(Wi)*hash(x,r,i)虽然慢，但是strawbucket能在item被编辑时得到最理想的数据移动。如果经常移除并且要求极高的重组效率，就是它了。47BucketTypeCRUSH:strawisdead,longlivestraw2straw2真正实现了增删节点，未改变节点的映射不会被影响max_x=-1max_item=-1foreachitem:x=randomvaluefrom0..65535x*=scalingfactorifxmax_x:max_x=xmax_item=itemreturnitemmax_x=-1max_item=-1foreachitem:x=randomvaluefrom0..65535x=ln(x/65536)/weightifxmax_x:max_x=xmax_item=itemreturn