45 个分布式存储典型问题解读（附物联网分布式存储技术的应用与分析）.docx

《45 个分布式存储典型问题解读（附物联网分布式存储技术的应用与分析）.docx》由会员分享，可在线阅读，更多相关《45 个分布式存储典型问题解读（附物联网分布式存储技术的应用与分析）.docx（21页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、涉及分布式存储选型、架构、运维等。1、分布式存储当前主要的应用场景有哪些？简单来说，就是存储设备分布在不同的地理位置，数据就近存储，将数据分 散在多个存储节点上，各个节点通过网络相连，对这些节点的资源进行统一的管 理，从而大大缓解带宽压力，同时也解决了传统的本地文件系统在文件大小、文 件数量等方面的限制。对于分布式存储，应用场景就很多了，如果你有以下需求: 数据量大、高吞吐量、高性能、高扩展，那就推荐分布式存储。主要的应用场景:1）块存储类似传统存储IPSan形式提供iSCSI接口，作为虚拟化后端存储2）对象存储视频，音频，图片类的存储，归档存储等，例如保险行业的“双录”系统， 电子保单系统3

2、）文件存储作为NFS, GPFS之类集群文件系统的替代品1、分布式块存储：（1）云平台，私有云建设，分布式存储非常适合云平台的场景，传统集中 式存储，一般都是标准iscsi协议挂载卷到openstack端，每个lun都需要单独挂 载。配置MPIO等。而分布式存储是通过rbd协议挂载存储池给OpenStack, OpenStack端直接在存储里划分和创建卷，调用快照等高级功能，分布式存储和 OpenStack是天生适配，更加合适OpenStack的私有云的发展。（2）容器场景：2018年12月发布Kubernetesl.13版本，用于容器编排引擎 的标准存储接口 containerstorage

3、interface （CSI）已普遍可用。在这些产品中，容 器本地数据服务的需求对于支持微服务结构变得非常重要，这些需求包括硬件不 可知性、API驱动、基于分布式架构，能够支持边缘、核心或公共云部署等。超 过70%的容器应用需要有状态数据持久化保存，SDS可以解决：需要敏捷的数 据迁移、从多个应用容器同时访问数据的需求。所以容器场景的弹性灵活的需求 也是非常适合分布式存储。2、分布式文件存储：分布式文件适合大容量文件存储场景，横向扩展灵活, 性能优于双控存储，例如非线编，共享NAS,高性能计算等等都非常适合，文 件存储也是现阶段三种存储中市场使用最高的，但有些也在慢慢转对象存储，对 象存储接口

4、协议在逐步开发中，会有一个过渡阶段。3、分布式对象存储：海量小文件需求，检索需求，大数据方向，金融的影 像平台，有互联网传输需求，和公有云整合，企业高校的网盘，监控等等非结构 化场景都适合，包括一些医疗的PACS也在逐步过渡到对象存储，未来最有爆发 潜力的存储。文件和对象都针对的非结构化场景，文件往对象转是大势所趋，在于对象 S3接口的逐步推广，对象存储支持文件和对象互操作（文件协议写入，对象方 式读出，反之亦然）也是顺应市场需求的产物。金融行业：影像系统、档案系统、容器、私有云、备份医疗行业：超融合、PACS影像存储安防行业：监控集中存储、智能安防教育行业：私有云、校园网盘除了 OLTP单一

5、业务极限IOPS需求，和极低时延（微秒），大部分业务场景 都可以通过SDS满足，金融领域的开发测试，容器云，电子影像，双录，广电方备份软件o是否需要备份建议针对业务系统保存的数据重要性级别而定，如业务系统数 据需进行本地、同城或异地备份，那么建议在应用端对需要备份的数据进行统一 备份，存储端不进行备份，这样可保持整体备份架构统一性，避免备份大量无用 数据造成备份设备容量浪费。应用端备份时可使用统一备份软件，如NBU、TSM 等。依然需要备份，分布式存储的副本或纠删码是防止存储部件损坏造成数据丢 失或业务暂停，哪怕分布式存储启用快照功能，也是无法防止物理故障。备份的 意义在于使用与存储完全隔离的

6、故障域来保护数据，分离的存储操作系统，不同 的物理设备，不同的物理区域，以防止物理故障，逻辑故障。方式的话有：1 .备份软件+硬盘设备或磁带设备；2 .存储之间的复制；3 .以及现在新的存储至对象存储方式，其本质是存储自带备份小软件将属于 备份到硬盘设备的方式。22、分布式存储节点超过内部通信交换机端口上限后，如何扩展内部通信交 换机？业务量大时交换机节点间通信是否会受阻？需要扩容内部交换机，分布式存储的交换机扩展方式与业务交换机的扩展方 式都是一致的，最好在网络架构规划时预留交换机在线扩展条件（包括交换机端 口等），以避免停机扩容带来的存储不可用。23、如何做包括元数据在内的数据迁移？打个比

7、方，大数据的cloudera集群，由于是商业化产品，通常有高可用， namenode都是高可用的，所以，你如果要搬机房迁移的话，我们做过（这是一 个悲剧，机房租用期到了），可以先迁移一个namenode,保证网络畅通（幸好是 迁移到隔壁机房），再迁移另外一个，然后再迁移各个datanode,基本用户无感 知。还是需要结合当前元数据的存储方式和数据迁移的目的综合考虑。24、AI训练或大数据分析是直接使用对象存储好，还是先把数据抽取到本 地文件系统好？抽取到本地存储,这绝对不是一个好的主意，大数据平台的数据量十分庞大, 所进行的操作涉及的数据，少则几个G,多达几十个T,如此多的数据，就算你 本地存

8、储够大，请问抽取传输要多少时间。所以，必定是在计算节点进行分析，可以的话，可以调用有GPU的计算节 点进行AI训练。至于对象存储，是可以的，现在aws上大数据分析，有的就是 基于对象存储。这个需要结合数据量的大小和本地文件系统和对象存储的访问性能来共同 决定。如果数据量过大已经超出了本地文件系统的支持容量，那么就要使用对象 存储。本地文件系统如果性能好很多，而数据又需要频繁读写，可以将数据预加 载到本地以提升性能。25、分布式存储场景中是否也可基于AIops进行一些智能运维？有什么建 议？在金融行业目前也有蛮多分布式存储集群案例，那基于存储所关心的集群存 储服务故障自愈、磁盘故障的SMART预

9、测是否也可以借鉴这套算法模型去设 计？算法本身与数据是如何存储的并无直接关系，基于分布式存储的大数据平台正是 机器学习、智能运维分析的奠基石，大量、丰富、有效的数据为算法分析提供了 分析的可能。磁盘故障的分析需要首先观察磁盘历史数据的趋势及分布，选择相 应算法可以实现有效的预测。故障自愈部分的建设需要结合专家建议，给出特定 场景下故障自愈方案才可以落地实现。26、从运维的角度看，分布式存储设计时要考虑哪些方面？运维管理中的监 控告警、备份恢复与异地容灾等应该如何规划？结合流行的ceph分布式做解释：（1）分布式存储监控:搭建分布式存储的开源软件通常都是服务器，是以服 务器自有磁盘来做存储的，所

10、以监控可以在服务器的磁盘上设置，同时，我们同 样可以用prometheus+grafana的方式进行监控，部署开源的ceph_exporter服务。（2）备份和恢复：分布式存储是不需要备份的，因为故障本身就在其软件 设计的计划中，比如ceph,设置2到| 3个mds+monitor, 45个osd,坏了几个 节点，可以从其他节点恢复。（3）异地灾备：比如ceph的RBD快照技术，通过差量文件的方式定期将 数据备份到灾备中心，当主数据中心发生故障时，从灾备中心恢复最近的备份数 据并重启相应的虚拟机，最大程度降低灾难时的数据恢复时间。在设计时应考虑到网络架构对性能的影响、监控内容的合理性、运维的便

11、捷 性等方面，监控告警主要为硬件类告警、操作系统告警、应用告警、性能容量告 警几大类，针对备份恢复及异地容灾建议在应用客户端进行按需备份容灾。27、如果选择基于开源软件的分布式存储技术路线，如何做好运维人才队伍 建设？如何做好软件产品平滑迭代？如何构建企业基于开源分布式存储系统的 业务生态？对于人才建设：1、找一两名在其他公司有实际落地经验的带头人，最好在社区比较活跃， 负责项目规划2、招聘几名应届实习生负责项目实施，这个过程一般会有新人脱颖而出对于产品迭代：只进行非常有必要的升级迭代，避免陷入无限升级的困境，同时在项目规划 之初考虑升级迭代的方式，对于分布式系统，逐台升级一般不影响业务使用对

12、于构建业务生态：由技术部架构选定场景，制定进相应技术规范中，并由开发、运维进行落实。28、Ceph在海量小文件的环境下，稳定性和扩展性如何？海量小文件存储（简称LOSF, lotsofsmallfiles）出现后，就一直是业界的难 题，许多互联网公司也针对自己的具体场景研发了自己的存储方案，还有一些公 司在现有开源项目基础上做针对性改造优化以满足业务存储需求；一、通过对若干分布式存储系统的调研、测试与使用，与其它分布式系统相 比，海量小文件存储更侧重于解决两个问题：1、海量小文件的元数据信息组织与管理：对于百亿量级的数据，每个文件 元信息按100B计算，元信息总数据量为1TB,远超过目前单机服

13、务器内存大小; 若使用本地持久化设备存储，须高效满足每次文件存取请求的元数据查询寻址 （对于上层有cdn的业务场景，可能不存在明显的数据热点），为了避免单点，还 要有备用元数据节点；同时z单组元数据服务器也成为整个集群规模扩展的瓶颈; 或者使用独立的存储集群存储管理元数据信息、，当数据存储节点的状态发生变更 时，应该及时通知相应元数据信息进行变更。对此问题，各分布式存储系统主要采用以下对策：1）设计时就在文件名中 包含了部分元数据信息，减小了元数据规模，元数据节点只负责管理粒度更大的 分片结构信息；2）通过升级优化硬件，使用分布式元数据架构一一多组（每组2 台）10性能更好的ssd服务器一一存

14、储集群的元数据信息、，满足单次10元数据查 询的同时，也实现了元数据存储的扩展性；3）系统模块提供了图片逻辑卷到物 理卷轴的映射存储与查询功能，通过cache集群来降低延时提高并发。2、本地磁盘文件的存储与管理（本地存储引擎）:对于常见的Linux文件系统, 读取一个文件通常需要三次磁盘10（读取目录元数据到内存，把文件的inode节 点装载到内存，最后读取实际的文件内容）；按目前主流2TB4TB的sata盘，可 存储2kw4kw个100KB大小的文件，由于文件数太多，无法将所有目录及文件 的inode信息缓存到内存，很难实现每个图片读取只需要一次磁盘IO的理想状 态，而长尾现象使得热点缓存无

15、明显效果；当请求寻址到具体的一块磁盘，如何 减少文件存取的io次数，高效地响应请求（尤其是读）已成为必须解决的另一问 题。对此问题，有些系统采用了小文件合并存储+索引文件的优化方案，此方案 有许多益处：a.合并后的合并大文件通常在64MB,甚至更大，单盘所存储的合 并大文件数量远小于原小文件的数量，其inode等信息可以全部被cache到内存, 减少了一次不必要的磁盘10; b.索引文件通常数据量（通常只存储小文件所在的 合并文件，及。ffset和size等关键信息）很小，可以全部加载到内存中，读取时 先访问内存索引数据，再根据合并文件、offset和size访问实际文件数据，实现 了一次磁盘

16、10的目的；c.单个小文件独立存储时，文件系统存储了其guid、属 主、大小、创建日期、访问日期、访问权限及其它结构信息，有些信息可能不是 业务所必需的，在合并存储时，可根据实际需要对文件元数据信息裁剪后在做合 并，减少空间占用。除了合并方法外，还可以使用IO性能更好的SSD等设备， 来实现高效响应本地io请求的目标。当然，在合并存储优化方案中，删除或修改文件操作可能无法立即回收存储 空间，对于存在大量删除修改的业务场景，需要再做相应的考量。29、Ceph可以配置单副本吗？【问题描述】采用Ceph搭建对象存储，用于小文件保存，几百TB的级别。 但是大部分文件几乎不会被访问，有点儿像一个归档存储

17、。如果使用两副本、三 副本，硬盘数量太多了。如果在底层配置RAID组，把VD给Ceph,只做单副 本，是否可行？不建议，建议硬盘直通进操作系统。做2-3副本保障数据安全。1、如果在底层配置RAID组，把VD给Ceph,只做单副本相当于每个VD 一个OSD。在VD出现问题后，由于数据是1副本，会数据丢失风险。2、底层RAID在做数据恢复时，也会影响ceph集群异常3、增加了集群运维难度，增大了集群风险点建议采用纠删码（EC）来解决，可以得到70.85%的磁盘空间使用效率，不 过性能比副本差一些。不建议配置单副本，为了保证系统的可用性和可靠性，必须采用两副本或者 三副本或者在原场地养老的模式30、

18、Ceph一个OSD应该分配多少内存？【问题描述】一个OSD应该分配多少内存？最近在测试Ceph集群，发现OSD占用的内存随着写入的数据越来越多，占用的内存也越来越多，最终都把 系统内存完了。root3138328.28,32593676920976?SslMar01332:07/usr/local/hstor/ceph_dir/bin/ ceph-osd-i42pid-file/var/run/ceph/osd.42.pid-c/usr/local/hstor/ceph_dir/etc/ceph/cep h.confclusterceph现在分配了多少内存出现问题了呢？ Ceph集群出现异常比

19、如数据重平衡会 大量使用内存，OSD内存消耗通常与系统中每个守护进程的PG数有关。内存问 题需要多注意，内存不够会导致。sd重启，集群异常。也给出了推荐的 OSD内存配置，可以参考一下，建议3-5GB吧。OSDs（ceph-osd）Bydefault,OSDsthatusetheBlueStorebackendrequire3-5GBofRAM.Youcanadjustt heamountofmemorytheOSDconsumeswiththeosd_memory_targetconfigurationoption whenBlueStoreisinuse.Whenusingthelegac

20、yFileStorebackend,theoperatingsystempage cacheisusedforcachingdata,sonotuningisnormallyneeded,andtheOSDmemoryconsump tionisgenerallyrelatedtothenumberofPGsperdaemoninthesystem.按照官网给的建议，每TB数据分配1GB内存较为适中，当然如果内存越 大越好，这样对于集群的数据均衡和高并发10处理上，不会产生性能瓶颈。 元数据服务器和监视器必须可以尽快地提供它们的数据，所以他们应该有足够的 内存，至少每进程IGBo OSD的日常

21、运行不需要那么多内存（如每进程500MB） 差不多了；然而在恢复期间它们占用内存比较大（如每进程每TB数据需要约1GB 内存）。通常内存越多越好。31、Ceph在激活OSD的时候提示没有权限？【问题描述】KVN虚拟机，按照手册进行部署的，前面没有提示错误，最 后激活OSD的时候提示没有权限。到OSDO, 0SD1两台机器的/var/local/osdO 和/var/local/osdl目录下看了一下，已经有文件存在了。不知道是哪的权限出了 问题！还是说python2.7的问题？查看下ceph用户对于/var/local/osdO/osdl有没有用户权限，可chown下权限 在尝试可以把具体的命

22、令行贴出来看下，一般这种问题肯定是权限设置没有设置好 导致的。32、如何对Ceph集群进行配置，同时运行多个mds服务？cephfs多mds默认是动态负载均衡的，为了负载文件系统请求到多个mdso cephfs会根据每个mds计算一个热点值，热点高的mds缓存中的目录会往热点 低的mds迁移，缓存中的目录在迁移的过程中是被锁定的，应用层的10不能访 问正在迁移的目录或文件，会导致部分10访问中断几秒。于是用户就感觉卡了。 有2种方案，两种方案是独立使用的。一，使用静态负载均衡，我们把业务绑定到mds,每次来业务我们根据mds 性能监控报表，把业务绑定到负载低的mds上去，也叫手动负载均衡。操作

23、过 程如下：1,把业务的根目录pin到mds上。假设给用户a分配了目录/A,用户b分配了目录/B,用户c分配了目录/C。那么我们把a用户分配到mdsO,把b用户分配到mds 1,把c用户分配到mds2osetfattr-nceph.dir.pin-v 1 /B2,设置cephfs的mds不迁移只需要设置cephfs的mds不迁移，就能让子目录不迁移。打 FF/etc/ceph/ceph.conf 文件配置mds_bal_min_rebalance= 1000每个mds者整产生一个热点值，这个热点值除以集群的总热点，然后和 mds_bal_min_rebalance 比较，超过 mds_bal_

24、min_rebalance 就会迁移，但 mds 的 热点面经过计算后怎么都不会超过1000的，所以只要配置 mds_bal_min_rebalance= 1000,多MDS之间就不会相互迁移缓存目录（不会产生 负莪均而），既然不迁移，子目录就会跟着父母走，/A/AA会跟着父目录/A绑定 到mdsO上，而/A/AA/AAA会跟着父目录/A/AA绑定到mdsO上。所以只要绑定 了业务的根目录，并且设置了 mds_bal_min_rebalance= 1000,用户目录就被固定 到了 mds上。多个用户可以绑定到同一个mds上。注意：只要使用这种模式，一定要绑定所有业务到mds上，否则业务会被 默

25、认分配到mdsO上，造成mdsO超载。二，使用动态负载均衡。依然采用默认的动态负载均衡，但是把迁移敏感度调小，让多mds之间迁 移的粒度变小，而不是一下子迁移整个大目录，导致卡了很长时间。目录迁移的 速度变快了，访问目录延迟的时间可以忽略不计。1,使多 mds 之间迁移粒度变小 mds_max_export_size=209715202,使mds之间热度的检测频繁变迟毓（用据场景适当调整）mds_bal_interval=10mds_bal_sample_interval=3.000000这瘁既价以使用动态负莪，后能避施负载均衡时候数据迁移导致的10夯死。33、Ceph在Windows下安装和

26、在Linux安装有什么区别？【问题描述】ceph-deployinstallceph-client这个命令在windows下安装的ceph 能用吗？查询 Ceph 社区（）目前 ceph-deploy 仅支持；Debian/UbuntuRHEL/CentOSopenSUSE对于windows还没有相关支持同上，一般集群都是采用Linux系统，安装部署会有专门的os版本；客户 端一般采用普通windows或者Linuxo34、Ceph集群出现了故障，如何确切知道影响到了哪些文件？【问题描述】Ceph向外提供文件系统，客户端mount到本地使用。如果集 群健康状态不正常（比如某些对象丢失），此时如

27、何知道哪些文件可用呢？Ceph同时提供对象存储、块存储、文件存储三种接口，但本质上其实是对 象存储，也就是说一个rbdimagc实际上包含了多个对象（默认情况下是 image_size/4M）o此处以块存储（RBD）为例进行演示，因为三种接口最终存储 文件的操作单元都是对象，所以其他接口的方法类似：前提：在 bloc 接口下有一个池：pooll,创建另一个 volume （rbdimage）： voll。 因为这个voll里其实包含了很多object,我们首先要查找object的位置：1 .查找vohime（rbdimage）的指纹信息2 .根据指纹找到这个volume的objectrados

28、-ppool 1 Is|grepbd85d5ffe883b3 .再根据object查找具体的存储位置rootcontroller-1 - #cephosdmappool 1 rbd_data.bd85d5ffe883b.000000000000 04a7进入到如下目录/Ceph/Data/Osd/osd-scsi-35000cca25e48d2e0/current,即可找到最终的存放文 件夹5.ljhead35、*哪些工具可以用来测试Ceph分布式文件系统的性能？【问题描述】在OSC内部搭建了一套Ceph分布式文件系统，共3个节点。 想对这个文件系统进行性能方面的测试，大家有什么好推荐呢？可以

29、通过性能测试工具进行文件系统测试如 VDBENCH、FIO 等比较常用的有fio, iozone, iometer0对于对象存储可以使用cosbench进行 测试。36、如何将块设备映像挂载到客户机？用三台虚拟机手动部署了 ceph集群，在集群上创建了一个test存储池和一 个叫testimage的1000M大小的块设备映像，请问如何将块设备映像挂载到一个 外部的客户机的/home/test目录下？rbdcreatetestsize 1024-pooltest-p_w_picpath-format2rbdinfotest-pooltestrbdmaptestpooltestrbdshowmap

30、pedmkfs.ext4/dev/rbdOmount/dev/rbdO/mnt首先在cephl管理节点上创建ceph块客户端用户名和认证密钥。其次安装ceph客户端。最后块设备的创建及映射。ceph集群中默认创建的块设备会在rbd池中创建，但是使用deploy的安装 方式部署的集群，rbd池默认不创建。客户端需要装ceph-common客户端吧，而且客户端需要访问该存储池的秘 钥，当然，如果只是为了做实验的话，可直接用admin。只要能保证客户端能访问ceph集群，其余的就是块存储挂载的正常命令， 网上很多挂载的，参考下。37、Ceph集群出现了故障，如何知道影响到了哪些文件？哪些文件还可用？

31、Ceph向外提供的是文件系统，客户端mount到本地使用。如果集群健康状 态不正常（比如某些对象丢失），如何知道哪些文件可用？那就要看是逻辑层上的故障还是物理层的故障了，逻辑层面的话可以通过副 本进行修复，物理层面的话就比较麻烦了。Ceph集群出现什么故障，如果只是逻辑上问题，修复后，所有文档都不会 损失；如果是物理层的故障，ceph有副本，只要不超过一定限度，仍然不会影 响到数据和文件；如果损失的，这个是物理层的，基本上追不回来了，除非用底 层的修复技术。38、cinder与cephosd的连接问题？cinder的volume进程是否对每一个cephosd都建立了一个TCP连接？ cinde

32、r 默认的文件描述符数是1024,那有很多。sd的时候，是否要把这个参数调高？(1 )ceph的少量的monitor组成的小规模集群，负责管理的M叩。ClusterM叩 是整个RADOS系统的关键数据结构，包含集群中全部成员、关系、属性等信息 以及管理数据的分发。ceph.conf文件中主要就是指定mon的节点的位置，所以 cinder服务需要和ceph的monitor保持连接，但不一定是tcp啊，内部的应该是 rpc连接。(2) cinder的文件描述符是个逻辑概念，和后端的osd,没有必然联系，应 该不需要调高。有很多osd的时候，有必要将默认的文件描述符数量调大，不然后边数量多 起来超过

33、1024的话会有报错。39、Ceph的块设备存储有良好的读写性能，可以组成共享文件系统，但同 时Ceph自身也有文件系统接口，请问两者有何区别？性能上孰高孰低？块存储读写快，不利于共享，文件存储读写慢，利于共享。能否弄一个读写 快，利于共享的出来呢。于是就有了对象存储。所以，Ceph的块存储是可以组成文件系统的，提供共享服务的，但没有这 个必要，因为服务器、网络以及NFS服务，你都要自行安排。除非一种情况， 你对文件系统共享的速度，乃至对象存储的速度均不满意，但又想要共享功能时, 你再可以考虑块设备存储组成共享文件系统的方案。特点是块存储读写快，但不利于共享，而文件存储读写慢，但有利于共享。

34、在性能上，块存储的性能高于文件存储。CephFS最大的问题是社区并不推荐上生产，请自行评估数据安全性。40、传统存储如何一键切换到分布式存储Ceph?我们行现在用的存储是华为5800,架构是同城双活，假如采用分布式存储, 如何升级迁移？(1)存储的形式基本上对用户的透明的，用户感知不到数据是在传统存储 上，还是在分布式存储上；(2)每个厂商对自己名下的数据迁移都有特定的解决方案。我感受最深的 是emc的scaleio,确实好用，性能又好，原来有试用版的，现在不知道有没有。 存储的切换，涉及应用和数据两个平面的工作。首先数据层面，如何做好数据迁移是做一键切换的基础，那么至少要有数据 在线迁移的方

35、案或者工具来做支撑；其次在数据迁移之后，应用怎么平滑切换应 用，也是要提前考虑的问题；所以并不是简单的存储替换问题，需要综合评估， 各个平面的适应性，兼容性，可能发生的影响，以及回退方案。对于存储来说， 如果有类似存储虚拟化或者存储纳管的功能，可能会让这个过程风险降低，趋于 平滑。添加分布式存储的映射关系，然后做数据的迁移。41 ceph对象存储osd分配不均匀,osdfull?200TB的集群，导入100来个T的数据就有osdfull (95%)是什么情况？看 osd状况，最大92%,最少58%,大部分在60-70%左右。CRUSH算法下为什么 会分布不均呢？crush算法不是万能的啊！(1

36、)哈希计算分配数据地址，存在一定的随机性，随着系统的使用，各个 存储节点的容量使用很不均衡，在一些不利配置的条件下，最大和最小容量之间最高相差50%,即使对数据进行复杂的重新分布均衡优化，也仅能达到90%左 右的容量使用率。造成容量的浪费；(2) crush算法中，有两次映射，对象到PG的映射是通过哈希值取模，对 象名是不可控的，因此只有在数据量大的情况，可以达到一个大致的均衡分布。 再就是第二次映射，ceph会生成一系列的pg数目，包含了一些osd列表，它是 一种伪随机算法，pg的数目也会影响数据均衡的效果，也会产生一些不稳定因 素。42、如何恢复Ceph的故障节点的硬盘上的数据？假设集群的

37、故障域为host,那么如果两个节点同时down掉，而且无法启动 这两个节点，但是节点的硬盘数据可以正常读取。那么我该如何将这两个节点的 数据导入到集群？导入会不会覆盖在节点down掉后写入到集群的对象呢？(1)如果真的是故障，故障磁盘重新加入集群，必先初始化，恢复不了；(2)如果不是故障，restart,可以重启磁盘读取数据；(3)故障磁盘没有必要去恢复，ceph都是有副本的。Ceph都是有副本数据的，如果是很严重的故障，故障磁盘只能重新加入集 群，必先初始化，恢复不了了。43目前企业Ceph应用版本该如何抉择;采用ssd+sata应用bulestore引擎？1：目前企业应用ceph的主流版本

38、是哪个版本，目前ceph已经到。版了， 那我现在部署的话建议部署哪个版本了？2：采用ssd+sata应用bulestore引擎，其中block.db和block.wal的大小该如 何设置，看过一些资料，建议block.db是主设备4%,那block.wal的大小建议如 何设置了 ？是与block.db的大小一样吗？(1) 一般LTS版本是当前年份往过去退2年左右，所以，现在的稳定版是 M 版 mimic o(2) wal 是 RocksDB 的 write-aheadlog,相当于之前的 journal 数据，db 是 RocksDB 的 metadata 信息。在磁盘选择原则是 block.

39、walblock.dbblock0 当然 所有的数据也可以放到同一块盘上。(3)默认情况下，wal和db的大小分别是512MB和1GB,官方建议调整 block.db是主设备4%,而block.wal分为6%左右，2个加起来10%左右。1、生产环境L版比较多。2、一般wal分区大于10G就足够使用，Ceph官方文档建议每个db分区不 小于每个数据盘容量的4%,比如：数据盘4T, db分区180G, wal分区60G。 具体可根据SSD或者NVME盘容量灵活设置。44、Ceph成熟的升级方案j版到L?目前公司项目中使用了 J版本的ceph,在页面管理不能实现，只能升级后才 能使用mgr,目前遇到

40、问题是：1、ceph即是数据节点又是openstack计算节点2、业务中使用的数据大概20t3、共计节点数70个有没有类似的升级方式可以参考？作为生产系统，有一个dashboard是很有必要的。(1)建议滚动升级到L版(2)寻求是否有其他第三方的dashboard可供J版使用；(3)根据cephapi接口，自己开发一个dashboard1、为了一个所谓的dashboard去升级ceph,是不是有点得不偿失？2、长远看自己写一个管理平台，可以兼容各种ceph版本收益更高，非得赖 着官方的dashboard可能会导致管理模块和ceph版本紧耦合，不得不跟着官方天 天升级，这就是从此折腾不断了。3、

41、官方的dashboard重构了不知道多少次了，最早的calamari时代到现在的 版本，来来回回的变，你要是贴着他们的版本，官方一旦弃坑就歇菜，这些都是 老司机们之前吃过的亏。45使用ceph-ansible安装好一个ceph集群，怎么才能在安装完更改集群 name 呢？可 以采用 命令：ceph-deploy-clustermydomnewceph-node文档中写了设置名字的命令ceph-deploy-clustermydomnewceph-node但是同时，又写了没有必要去设置集群名字。应该是原先是有这功能的，但后来被开发小组移除了，以下是移除该功能的 公告，供参考：建议在部署过程中修改

42、配置文件进行集群name修改，部署完成 后集群name配置较为分散，容易修改不完全，可能会导致集群访问异常。物联网分布式存储技术的应用与分析摘要：随着物联网业务的兴起，参与网络连接的终端迅速增多，由此产生了 海量数据。对于数据的存储，从数据收集的途径、分析开发实际需求以及安全性 出发，分布式存储是最佳选择。关键词：物联网；分布式；存储技术；终端。引言近年来，随着网络技术和通信技术，特别是无线通信技术的快速发展，人类 社会逐渐进入物物相联的时代。虽然物与物之间的信息交换单次信息量不大，但 由于终端数量庞大，将会生成海量数据。如何更好地存储这些数据是物联网络系 统建设者需要思考的问题。1物联网行业

43、发展现状20世纪90年代至今，物联网经历了漫长的发展过程。直到2009年，物联 网被正式列为国家五大新兴战略性产业之一，并写入当年的政府工作报告， 随即物联网受到了社会的极大关注和大量人力、物力资源的投入，并开始迅速发 展。2016年12月18日，工业和信息化部印发的信息通信行业发展规划物联 网分册(2016-2020年)(简称物联网分册)指出，2015年底我国物联网产 业规模已达7500亿元，整个“十二五”期间年均复合增长率达到25%。我国机器 与机器连接数突破1亿，占全球总量的31%,成为全球最大市场。“十三五”期间, 随着万物互联时代开启，我国物联网产业规模也将保持高速发展势头，预计20

44、17 年，产业规模将达到万亿级。2物联网业务对分布式存储的需求物联网分为应用层，数据层，网络层和感知层。对网络层来说，虽然在物联 网大力发展时期将面临大量通信节点暴增的挑战，但按照有序发展支撑和演进式 逐步建设的规划，目前的网络资源仍然足够支撑业务增长。在充分利用现有网络 资源的前提下，依据业务实际增长情况逐步扩展，分阶段改造网络，逐步完成网 络层的建设。物联网应用所带来的数据量和数据读写业务压力不同以往，数据层所面临的 挑战相对而言更大。与传统业务相比，这方面的需求都呈指数级增长，远高于现 有系统的承载能力。物联网的典型应用通常包括海量传感器，数量可达数百万个, 采样频率也较高。虽然单个数据

45、并不大，但积少成多，因此数据总量非常可观。 这两种情况的结合，即要求存储系统能并发处理数百万个传感器的高频数据写 入，并发压力和传统生产系统有着数十倍乃至上百倍的差异。一个典型的物联网 存储子系统可能需要支持数千亿个小文件的存储，同时需提供超高的并发读写性 能支撑。由于视频监控也是典型的物联网应用，来自各类固定、移动监控摄像头甚至 无人机的监控录像和高清图片也是物联网存储系统所要处理的数据类型。此类数 据类型通常是连续的视频流，而并发的高带宽和海量存储空间需求也是前所未有 的巨大挑战。同时，由于物联网“物”的特征，很多时候并不需要像人类参与的工 种一样有典型的时间周期，物联网系统经常全年无休，

46、每时每刻都在不知疲倦地 产生数据，同时由于业务本身持续不断，因此对存储系统的高可用性也有很强的 需求。从数据类型上看，相对传统业务的结构化数据占比较高，物联网应用和新业 务将产生大量的非结构化和半结构化数据，这也将对存储系统提出新的挑战。物联网大规模的数据存储或计算需求通过控制节点分发到各物理机，采用分 布式存储方案解决了传统集中计算存储存在的性能瓶颈问题和成本问题，近年来 获得了广泛应用。3分布式存储CAP理论CAP是分布式系统设计中的经典理论，也是工程实施和产品研发中的基本 理论依据，对分布式存储产品设计、选型、实施具有指导意义。这一理论由 EricBrewer在2000年的PODC会议上

47、提出，最初仅仅是一个猜想，2年后被MIT 的SethGilbert和NancyLynch证明为理论，并很快被互联网企业如Ebay, Twitter, Amazon等接受和拥护。17年来，该理论已被广泛应用于各类分布式系统设计中。 CAP理论简单说来只有一句话：在分布式系统中，一致性(Consistency),可用 性(Availability)和分区容忍性(Partition-Tolerance)三种特性只能同时实现其 中部分，常取其中两种，舍弃一种。3.1 数据一致性如果系统对一个写操作返回成功，那么之后的读请求都能读到这个新数据； 如果返回失败，那么所有读操作都不能读到该数据，对调用者而言

48、，数据具有强 一致性(StrongConsistency ),又叫原子性(Atomic ),线性一致性 (LinearizableConsistency)。无论对数据如何操作，该特性可保证得到的数据都是完成状态的数据，否则 操作失败。类似于原子性的概念，一个操作必须是完整的，杜绝牵扯不清的中间 状态。对数据的修改必须保证最终数据是原子操作的合格品，否则失败退出，决 不能出现修改了一半的数据半成品。例如多个应用并发对系统调用时，应用不会 得到一张被另外一个应用请求画了一半的图，或更新了上半段的说明书。3.2 服务可用性在指定的响应时间窗口内，每个操作请求都能到响应并返回，不会持续等待。 该特性接近实时系统的定义，能够确保系统及时响应，避免死锁，从而为更多的 并发业务和应用提供“可用”的服务。3.3 分区容忍性保证系统支持分区，在分裂的情况下，各节点仍可正常提供服务，支撑业务 和应用。领域的媒资，CDN,等等，都是当前SDS能够应对的场景，简单来讲，SDS本 身是分