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

涉及分布式存储选型、架构、运维等。1、分布式存储当前主要的应用场景有哪些？简单来说，就是存储设备分布在不同的地理位置，数据就近存储，将数据分散在多个存储节点上，各个节点通过网络相连，对这些节点的资源进行统一的管理，从而大大缓解带宽压力，同时也解决了传统的本地文件系统在文件大小、文件数量等方面的限制。对于分布式存储，应用场景就很多了，如果你有以下需求:数据量大、高吞吐量、高性能、高扩展，那就推荐分布式存储。主要的应用场景:1）块存储类似传统存储IPSan形式提供iSCSI接口，作为虚拟化后端存储2）对象存储视频，音频，图片类的存储，归档存储等，例如保险行业的“双录”系统，电子保单系统3）文件存储作为NFS,GPFS之类集群文件系统的替代品1、分布式块存储：（1）云平台，私有云建设，分布式存储非常适合云平台的场景，传统集中式存储，一般都是标准iscsi协议挂载卷到OPenStaCk端，每个km都需要单独挂载。配置MPlO等。而分布式存储是通过rbd协议挂载存储池给OPenStack,OPenStaCk端直接在存储里划分和创建卷，调用快照等高级功能，分布式存储和OpenStack是天生适配，更加合适OPenStaCk的私有云的发展。（2）容器场景：2018年12月发布KUbemeteSI.13版本,用于容器编排引擎的标准存储接口containerstorageinterface（CSI）已普遍可用。在这些产品中，容器本地数据服务的需求对于支持微服务结构变得非常重要，这些需求包括硬件不可知性、APl驱动、基于分布式架构，能够支持边缘、核心或公共云部署等。超过70%的容器应用需要有状态数据持久化保存，SDS可以解决：需要敏捷的数据迁移、从多个应用容器同时访问数据的需求。所以容器场景的弹性灵活的需求也是非常适合分布式存储。2、分布式文件存储：分布式文件适合大容量文件存储场景，横向扩展灵活,性能优于双控存储，例如非线编，共享NAS,高性能计算等等都非常适合，文件存储也是现阶段三种存储中市场使用最高的，但有些也在慢慢转对象存储，对象存储接口协议在逐步开发中，会有一个过渡阶段。3、分布式对象存储：海量小文件需求，检索需求，大数据方向，金融的影像平台，有互联网传输需求，和公有云整合，企业高校的网盘，监控等等非结构化场景都适合，包括一些医疗的PACS也在逐步过渡到对象存储，未来最有爆发潜力的存储。文件和对象都针对的非结构化场景，文件往对象转是大势所趋，在于对象S3接口的逐步推广，对象存储支持文件和对象互操作（文件协议写入，对象方式读出，反之亦然）也是顺应市场需求的产物。金融行业：影像系统、档案系统、容器、私有云、备份医疗行业：超融合、PACS影像存储安防行业：监控集中存储、智能安防教育行业：私有云、校园网盘除了OLTP单一业务极限IOPS需求，和极低时延（微秒），大部分业务场景都可以通过SDS满足，金融领域的开发测试，容器云，电子影像，双录，广电领域的媒资，CDN,等等，都是当前SDS能够应对的场景，简单来讲，SDS本身是分布式架构，通过ScaleUp和ScaleOut对标准化服务器和网络的排列组合，可以获得业务希望获得的存储能力。2、和传统存储相比，分布式存储在哪些应用场景比较有优势？分布式存储适用于虚拟化、云平台对接场景,海量非结构化数据保存场景（如图片、影音等）。数据量大、局吞吐量、性能、扩展等场景。分布式在整体架构设计上，可按需配置，灵活扩展；分布式存储性能上限高，传统存储传输接口数量受限制有天花板；分布式存储容量上限高，横向扩展能力强；分布式存储硬件节点做替换对应用影响小；综上所述，在私有云部署，海量非结构化数据，高性能计算，流媒体和视频监控场景有比较大的优势。3、传统存储架构的局限性和分布式存储的优点？传统SAN存储设备一般采用双控制器架构，两者互为备份，配置两台交换机与前端的服务器进行连接，这种双控制器架构方式会有以下两个方面的缺点：1 .网络带宽容易变成整个存储性能的瓶颈；2 .如果一个控制器损坏，系统的性能将大幅下降，影响存储的正常使用。传统存储架构的局限性主要体现在以下几个方面：1、横向扩展性较差受限于前端控制器的对外服务能力，纵向扩展磁盘数量无法有效提升存储设备对外提供服务的能力。同时，前端控制器横向扩展能力非常有限，业界最多仅能实现几个控制器的横向。因此，前端控制器成为整个存储性能的瓶颈。2、不同厂家传统存储之间的差异性带来的管理问题不同厂商设备的管理和使用方式各有不同，由于软硬件紧耦合、管理接口不统一等限制因素无法做到资源的统一管理和弹性调度，也会带来存储利用率较低的现象。因此，不同存储的存在影响了存储使用的便利性和利用率。分布式存储往往采用分布式的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息。它不但提高了系统的可靠性、可用性和存取效率，还易于扩展，将通用硬件引入的不稳定因素降到最低。优点如下：1 .高性能一个具有高性能的分布式存户通常能够高效地管理读缓存和写缓存，并且支持自动的分级存储。分布式存储通过将热点区域内数据映射到高速存储中，来提高系统响应速度；一旦这些区域不再是热点，那么存储系统会将它们移出高速存储。而写缓存技术则可使配合高速存储来明显改变整体存储的性能，按照一定的策略，先将数据写入高速存储，再在适当的时间进行同步落盘。2 .弹性扩展得益于合理的分布式架构，分布式存储可预估并且弹性扩展计算、存储容量和性能。分布式存储的水平扩展有以下几个特性：1）节点扩展后，旧数据会自动迁移到新节点，实现负载均衡，避免单点过热的情况出现；2）水平扩展只需要将新节点和原有集群连接到同一网络，整个过程不会对业务造成影响；3）当节点被添加到集群，集群系统的整体容量和性能也随之线性扩展，此后新节点的资源就会被管理平台接管，被用于分配或者回收。3 .支持分级存储由于通过网络进行松耦合链接，分布式存储允许高速存储和低速存储分开部署，或者任意比例混布。在不可预测的业务环境或者敏捷应用情况下，分层存储的优势可以发挥到最佳。解决了目前缓存分层存储最大的问题是当性能池读不命中后，从冷池提取数据的粒度太大，导致延迟高，从而给造成整体的性能的抖动的问题。4 .多副本的一致性与传统的存储架构使用RAlD模式来保证数据的可靠性不同，分布式存储采用了多副本备份机制。在存储数据之前，分布式存储对数据进行了分片，分片后的数据按照一定的规则保存在集群节点上。为了保证多个数据副本之间的一致性，分布式存储通常采用的是一个副本写入，多个副本读取的强一致性技术，使用镜像、条带、分布式校验等方式满足租户对于可靠性不同的需求。在读取数据失败的时候，系统可以通过从其他副本读取数据，重新写入该副本进行恢复，从而保证副本的总数固定；当数据长时间处于不一致状态时，系统会自动数据重建恢复，同时租户可设定数据恢复的带宽规则，最小化对业务的影响。5 .容灾与备份在分布式存储的容灾中，一个重要的手段就是多时间点快照技术，使得用户生产系统能够实现一定时间间隔下的各版本数据的保存。特别值得一提的是，多时间点快照技术支持同时提取多个时间点样本同时恢复，这对于很多逻辑错误的灾难定位十分有用，如果用户有多台服务器或虚拟机可以用作系统恢复，通过比照和分析，可以快速找到哪个时间点才是需要回复的时间点，降低了故障定位的难度，缩短了定位时间。这个功能还非常有利于进行故障重现，从而进行分析和研究，避免灾难在未来再次发生。多副本技术，数据条带化放置，多时间点快照和周期增量复制等技术为分布式存储的高可靠性提供了保障。6 .存储系统标准化随着分布式存储的发展，存储行业的标准化进程也不断推进，分布式存储优先采用行业标准接口进行存储接入。在平台层面，通过将异构存储资源进行抽象化，将传统的存储设备级的操作封装成面向存储资源的操作，从而简化异构存储基础架构的操作，以实现存储资源的集中管理，并能够自动执行创建、变更、回收等整个存储生命周期流程。基于异构存储整合的功能，用户可以实现跨不同品牌、介质地实现容灾，如用中低端阵列为高端阵列容灾，用不同磁盘阵列为闪存阵列容灾等等，从侧面降低了存储采购和管理成本。4、分布式存储与传统的SAN、NAS相比的优势和缺点？分布式存储与传统的SAN、NAS相比，优势如下：1、性能：在分布式存储达到一定规模时，性能会超过传统的SAN、NASo大量磁盘和节点，结合适当的数据分布策略，可以达到非常高的聚合带宽。传统的SAN、NAS都会有性能瓶颈，一旦达到最大扩展能力，性能不会改变甚至降低。2、价格：传统的SAN>NAS,价格比较高。特别是SAN网络设备，光纤网络成本比较高。而且，以后扩展还需要增加扩展柜。成本太高。分布式存储只需要IP网络，几台X86服务器加内置硬盘就可以组建起来，初期成本比较低。扩展也非常方便，加服务器就行。3、可持续性：传统的SAN、NAS扩展能力受限，一个机头最多可以带几百个磁盘。如果想要个PB以上的共享存储，分布式存储是最好的选择。不用担心扩展能力问题。缺点：1、需要比较强的技术能力和运维能力，甚至有开发能力的用户。传统存储开箱即用，硬件由厂家提供，也有完善的文档和服务。而分布式很多是开源或者是有公司基于开源系统提供支持服务，版本迭代比较快，出问题后有可能需要自己解决。2、数据一致性问题。对于OraCIeRAC这一类对数据一致性要求比较高的应用场景，分布式存储的性能可能就稍弱了，因为分布式的结构，数据同步是一个大问题，虽然现在技术一直在进步，但是也不如传统存储设备数据存储方式可靠。3、稳定性问题。分布式存储非常依赖网络环境和带宽，如果网络发生抖动或者故障，都可能会影响分布式存储系统运行。例如，一旦发生IP冲突，那么整体分布式存储可能都无法访问。传统存储一般使用专用SAN或IP网络，稳定性方面，更可靠一些。5、分布式存储如何保证数据一致性？从服务端角度，如何尽快将更新后的数据分布到整个系统，降低达到最终一致性的时间窗口，是提高系统的可用度和用户体验非常重要的方面。对于分布式存储系统：N一数据复制的份数W一更新数据是需要保证写完成的节点数R一读取数据的时候需要读取的节点数如果W+R>N,写的节点和读的节点重叠，则是强一致性。例如对于典型的一主一备同步复制的分布式存储系统，N=2,W=2,R=1,则不管读的是主副本还是从副本的数据，都是一致的。如果W+R<=N,则是弱一致性。例如对于一主一备异步复制的分布式存储,N=2,W=l,R=I,则如果读的是从副本,就可能无法读取主副本已经更新过的数据,从而读到了脏数据所以是弱一致性。对于分布存储式系统，为了保证高可用性，一般设置N>=3,且强制在主副本读取，也是通常说的分布式存储系统使用强一致性原则。6、分布式存储的文件存储和对象存储有哪些区别？文件存储与对象存储区别主要可从三方面来进行比较：1、展现模式：文件存储：以盘符/目录的形式展现，优点是符合用户现有使用习惯，用户可以像使用本地硬盘一样使用存储系统，缺点是无法定制化存储元数据信息，对业务系统无优化；对象存储：与应用系统相结合形式展现，优点是可按需调用存储接口，并为文件设置元数据以及标签属性，可满足业务系统定制化需求，缺点是需要业务系统直接调用存储，用户无法直接调用系统内数据。2、访问协议文件存储：NFS/CIFS协议访问，优点是锁机制可支持多人同时对数据进行修改（锁机制由应用系统决定,缺点是为保证数据访问一致性，需要进行数据索引信息同步，对系统并发性能以及系统规模存在较大影响。对象存储：HTTP传输协议以及RESTfUl接口访问，优点是通过算法存放文件元数据信息，无元数据同步限制，系统可无限制扩展，且性能随着存储系统规模扩展而线性提升，缺点是采用RESTfUl接口Put、Get、Delete,不支持多人同时对同一文件修改。3、数据结构文件存储：采用树形目录结构，读取和存储数据要经过更长路径才能到达目标位置。随着数据越来越多，目录结构会越来越繁杂，查找以及调取文件的速度会越来越慢（操作系统对目录字节数存在限制）；如若出现设备损坏或者扩容时,需要将巨型目录树中的数据重新分配均衡，效率较差。对象存储：采用扁平目录结构，抛弃了嵌套的文件夹，避免维护庞大的目录树，只保留二级（或三级）目录结构。根下直接就是桶，桶中直接存放对象，桶中不能再建桶（禁止多层文件夹）。每个对象文件都只需要一个ID就能获取对象。适用场景总结：文件存储：数百TB-PB级数据并行计算类应用；亿级别以内小文件存储类应用；需要在线修改数据类应用系统，如：非编系统。对象存储：PB-数百PB级数据存储存储类应用；千亿级海量小文件数据存储以及海量并发。7、关于主流分布式文件存储的适用场景？【问题描述】主流分布式文件存储，比如Ceph、MogileFS>TFS.FastDFS>GlUSterFS的适用场景有什么区别？哪些适合单集群，哪些适合跨集群？分布式文件存储的功能、架构设计大同小异，适用场景也基本一致，如何选择更大程度上还是取决于社区的活跃度，一般用户很少有能力去做代码级别的研究，因此社区中安装、部署、运维文档的完整度，社区的活跃度是选择产品时重要的决策点。8、各大分布式文件系统优劣势对比，读写对比，性能对比，数据安全性对比，使用场景对比？各分布式文件系统数据安全性、使用场景区别不大，读写性能更取决于硬件配置，各产品区别主要在于发展过程不同带来的使用场景倾向不同，如CePh之于OPenStack,GIUSterfS之于OPenShift,建议根据不同用途选择该用途下使用最多的产品，一般这种常见的坑都被踩过了，更稳定、性能更好一些。9、分布式存储技术路线选型探讨：HDFSCeph>GFS>GPFS>SWift等各种技术的特点和适用场景？【问题描述】随着数字化转型的深入，海量数据对存储提出了新的要求。传统存储虽然有技术成熟、性能良好、可用性高等优点，但面对海量数据，其缺点也越来越明显：如扩展性差、成本高等。为了克服上述缺点，满足海量数据的存储需求，市场上出现了分布式存储技术。当前，分布式存储有多种实现技术，如HDFS、Ceph>GFS>GPFS、Swift等。在实际工作中，为了更好地引入分布式存储技术，我们需了解各种分布式存储技术的特点，以及各种技术的适用场景，在此希望请教下同行，城商行应该如何选择这些分布式存储技术，他们各自的特点和场景如何？在以上几种分布式存储技术中，每一种存储技术都有各自的特点和应用场景。其中HDFS、CePh和SWift应用比较多，这也和它们的技术发展比较快和应用场景比较多相关。下面分别介绍：一、HDFS主要用于大数据的存储场景，是Hadoop大数据架构中的存储组件。HDFS在开始设计的时候，就已经明确的它的应用场景，就是为大数据服务。主要的应用场景有：1、对大文件存储的性能比较高，例如几百兆，几个G的大文件。因为HDFS采用的是以元数据的方式进行文件管理，而元数据的相关目录和块等信息保存在NameNOde的内存中，文件数量的增加会占用大量的NameNOde内存。如果存在大量的小文件，会占用大量内存空间，引起整个分布式存储性能下降，所以尽量使用HDFS存储大文件比较合适。2、适合低写入，多次读取的业务。就大数据分析业务而言，其处理模式就是一次写入、多次读取，然后进行数据分析工作，HDFS的数据传输吞吐量比较高，但是数据读取延时比较差，不适合频繁的数据写入。3、HDFS采用多副本数据保护机制，使用普通的X86服务器就可以保障数据的可靠性，不推荐在虚拟化环境中使用。二、Ceph是一个开源的存储项目，是目前应用最广泛的开源分布式存储系统，已得到众多厂商的支持，许多超融合系统的分布式存储都是基于CePh深度定制。而且Ceph已经成为LINUX系统和OPenStaCk的“标配”，用于支持各自的存储系统。Ceph可以提供对象存储、块设备存储和文件系统存储服务。同时支持三种不同类型的存储服务的特性，在分布式存储系统中，是很少见的。Ceph没有采用HDFS的元数据寻址的方案，而且采用CRUSH算法，数据分布均衡，并行度高。而且在支持块存储特性上，数据可以具有强一致性，可以获得传统集中式存储的使用体验。对象存储服务，Ceph支持Swift和S3的APl接口。在块存储方面，支持精简配置、快照、克隆。在文件系统存储服务方面，支持POSiX接口，支持快照。但是目前CePh支持文件的性能相当其他分布式存储系统，部署稍显复杂，性能也稍弱，一般都将CePh应用于块和对象存储。Ceph是去中心化的分布式解决方案，需要提前做好规划设计，对技术团队的要求能力比较高。特别是在CePh扩容时，由于其数据分布均衡的特性，会导致整个存储系统性能的下降。三、GFSGFS是google分布式文件存储，是为了存储海量搜索数据而设计的专用文件系统。和HDFS比较类似，而且HDFS系统最早就是根据GFS的概念进行设计实现的。GFS同样适合大文件读写，不合适小文件存储。适合处理大量的文件读取，需要高带宽，而且数据访问延时不敏感的搜索类业务。同样不适合多用户同时写入。GFS是最早的推出分布式存储概念的的存储系统之一，后来的大部分的分布式式文件系统或多或少都参考了GFS的设计。HDFS和GFS的主要区别是，对GFS中关于数据的写入进行了一些改进，同一时间只允许一个客户端写入或追加数据。而GFS是支持并发写入的。这样会减少同时写入带来的数据一致性问题，在写入流程上，架构相对比较简单，容易实现。四、GPFSGPFS是IBM的共享文件系统，它是一个并行的磁盘文件系统，可以保证在资源组内的所有节点可以并行访问整个文件系统。GPFS允许客户共享文件，而这些文件可能分布在不同节点的不同硬盘上。GPFS提供了许多标准的UNIX文件系统接口，允许应用不需修改或者重新编辑就可以在其上运行。GPFS和其他分布式存储不同的是，GPFS是由网络共享磁盘(NSD)和物理磁盘组成。网络共享磁盘(NSD)是由物理磁盘映射出来的虚拟设备，与磁盘之间是一一对应的关系。所以，使用两台传统的集中式存储设备，通过划分不同的网络共享磁盘，也可以部署GPFS,不一定部署在X86设备上。GPFS文件系统允许在同一个节点内的多个进程使用标准的UNIX文件系统接口并行的访问相同文件进行读写，性能比较高。GPFS支持传统集中式存储的仲裁机制和文件锁，保证数据安全和数据的正确性，这是其他分布式存储系统无法比拟的。GPFS主要用于IBM小型机和UNIX系统的文件共享和数据容灾等场景。五、SwiftSWift也是一个开源的存储项目，但是主要面向的是对象存储。和CePh提供的对象存储服务类似。主要用于解决非结构化数据存储问题。它和CePh的对象存储服务的主要区别是。1、客户端在访问对象存储系统服务时，SWift要求客户端必须访问SWift网关才能获得数据。而C叩h使用一个运行在每个存储节点上的OSD（对象存储设备）获取数据信息，没有一个单独的入口点，比SWift更灵活一些。2、在数据一致性方面，Swift的数据是最终一致，在海量数据的处理效率上要高一些，但是主要面向对数据一致性要求不高，但是对数据处理效率要求比较高的对象存储业务。而CePh是始终跨集群强一致性。主要的应用场景，在迪OpenStack中，对象存储服务使用的就是Swift,而不是Cepho10、Ceph>MogileFS>TFSsFastDFSGlusterFS,是否都支持跨集群同步?分布式存储一般不建议配置跨集群同步，其本来就是采用网络IO的方式，如果配置跨集群同步，会导致IO过长，可能影响读写延迟，建议配置重要数据同步复制即可，可使用rsync之类的工具。11>块存储与文件存储的对比？【问题描述】我想请问一下块存储与文件存储的详细对比？比如说，块存储比文件更稳定，时延低，为什么？块协议比文件协议怎么稳定，体现在哪?文件协议开销大，体现在哪？实际测试结果来看，块存储和文件存储的稳定性、时延并没有明显区别。块存储和文件存储的使用场景不一样，块存储主要用于提供VMware或者OPenStaCk做存储卷用，而文件系统存储主要用于文件在容器、虚拟机及物理机之间的文件共享存储。12、在KUbenleteS上用分布式的存储方案进行容器数据的存储，哪个分布式的存储系统可以直接部署起来使用？GlusterFS>CePh都可以直接使用使用GlanCeFS、GFS或CePh都可以，但是如果是用于数据库的话，不得不说,效率不高啊！就算使用flashdisk,效率也基本上等于SAS盘的速度。13、影像数据，如果是图像比较大的情况，一张图接近GB时，选择哪种开源产品比较合适？可以使用CePh对象存储协议来保存，建议单独建设一个资源池针对这种大图像来进行存储，可以通过增大对象条带大小的方式获得更好的读写性能。首先表个态，图像照片，特别是尺寸大的，是不太适合直接存放在数据库中的，但如果要存放，开源的数据库MySQL就可以，其实就是放在CIOb字段中，dob字段是MySQL从OraCIe继承过来的，0racle8i的时候，就可以存放4g的二进制文件，所以，现在MySQL完全可以存放。其次，正确的方法，是在数据库中存放一个链接，将图像照片存放在OSS对象存储上，或干脆在磁盘上。存放在数据库中效率怎么都是不高的。14、金融行业如何针对结构化与非结构化数据，进行分布式存储的选型？【问题描述】金融行业如何针对结构化与非结构化数据，进行分布式存储的选型？尤其像客服中心语音数据与信贷类交易系统的影像文件等非结构化数据，如何既经济又安全地选择市场上高口碑和好评的分布式存储进行对接？需要结合不同的使用场景进行POC测试，有些产品可能在特定的场景下比较合适，因此可针对非结构化数据存储和结构化数据存储分别进行POC测试。结构化数据的分布式存储，实际上就是分布式关系型数据库的存储，使用的2pc或3pc的提交模式。为了保证结构化数据的事物一致性，这类数据的分布式存储比较好的是选用ra九架构。非结构化数据，大都是非关系型数据库，只要保证数据的最终一致性，一致性的要求比较低，所以比较自由，HDFS.GFS都可以选择，最简单的就是Hive,你可以把它理解成为一个非结构化数据仓库，底层是对HDFS等分布式存储的的读写。15、把现有影像系统的非结构化数据集中存贮到一起，供AI、Bl等平台使用，使用对象存储是否合适？特别合适，对象存储比较适合存储影像、语音等非结构化数据。对象存储的特点是，你可以理解为是个大U盘，可以读，但不适合于写。放置只读不改的影像数据是合适的。事实上，对象存储通常也放置一些网站的图片，供网站加载时使用，只是没有CDN强。缺点是，安全性较差，你要确定你的影像数据无敏感数据，如果有对象存储中，可以有多种加密手段。16、一套分布式存储节点规模在多少台合适？开个玩笑:抛开需求谈规模都是耍流氓一一有实际的业务场景,量化的数据、流量规模才有测试结论。1、如果是采购三方系统，对于CAP中的原则问题不是在我们的考虑范围，对于节点的配置涉及分布式系统的底层设计：数据同步（分片）、数据备份、master选举等。我们要做的就只有一点：看配置文件说明，遵循官方的节点配置公式。比较经典的节点配置公式：2/n+l（n为节点数），也就是集群中需要保证有半数以上的节点正常，这样可以保证master的半数投票获得率，数据备份也是同理。所以一般为达到机器的较高利用率节点数一般是：3、5、7、9.,视规模变化。2、如果是自己设计一套分布系统，那考虑的问题不只是CAP原则还有，还有应用程序的可伸缩性，弹性和可管理性等。微软AZUre应用设计原则感觉是不错的指导，建议看看，从分布式开发者角度出发了解分布式应用。分布式存储理论上的是没有节点上线的，可以无限扩展。但是，现实的情况是，超过500台节点后，整个集群的性能并不会随着节点的增加而增加，并且可能会出现集群数据重构导致的集群不稳定。按照实际使用的情况，一般分布式集群存储容量超过70%的可用容量时，集群扩容会对集群性能产生巨大的影响。所以，一般做POC的时候，建议先把集群数据写满，然后擦除40%,在存有60%数据的集群上做POG这个结果比较靠谱。17、集中式存储向分布式存储的转型，有哪些技术难点和运维管理困难？转型前期、中期和后期都有哪些注意的要点，对于渠道类、账务类和数据报送类业务，如何合理、分批次进行转型？技术难度：i。的读写，集中存储中数据只要写入一个磁阵就算成功了，分布式存储中是写入大部分的节点才算成功，如果写入全部节点IO性能有影响，写入少量节点即是写入失败。运维困难：监控上，要采用分布式prometheus来采集各个节点的数据，节点多的时候，监控范围较大。出现故障时，要判断节点与节点间的相互作用，诊断难度加大。对不同类型的数据应采用不同的迁移方式：（1）对渠道类数据通常是多而散，通常分批迁移；（2）对于账务类数据，通常是实时数据，需要保证其关联性和事务性，需要择业务运维窗口迁移，同时做好新老数据同步工作（3）对于数据报送类数据，通常是交易历史数据等，可以择时一次性迁移。在迁移前期，会有数据不同步的现象，需要新老系统并存；在中期，需要进行必要的数据校验和压力测试（分布式存储读写性能很重要），后期在校验同步基础上，进行迁移（转型）的演练，将少量应用的数据源切换到分布式存储，进行预生产发布。可以先行保留存储访问协议不变，先将集中式存储转为分布式存储；然后在稳定运行一段时间后逐步将存储协议转换为适合分布式存储访问的对象存储协议。18、分布式存储如何做好集群运维？分布式存储做好集群的运维非常的关键，因为正常情况下一个分布式存储是运行一个节点挂掉，如果多个节点挂掉，将会导致分布式存储的灾难。我的推荐如下：L保障性运维，关注在节点服务器的稳定运行，如机器，磁盘，SSD,RAID卡，电池等等，这些关键组件的状态监控；故障后及时的处理；2 .标准化故障处理、增加节点的流程；3 .建立存储服务交付，存储使用配额的管理等等。1、良好的架构设计运维成功的一半；3、及时处理小问题；4、熟悉技术原理，避免小问题引发大的故障。如硬盘损坏导致集群整体性能问题。19、集群规模控制在多少节点，即可以发挥分布式多节点IO的性能优势，又可以防止集群过大造成性能下降？一般推荐的集群规模为20个节点至30个节点，超过30个节点后扩容及故障带来的数据重分布数据量会很大，耗时较长，增加了存储访问不稳定性。20、如何防止单个磁盘访问缓慢影响整体集群性能？可针对磁盘IO情况设置监控阈值，当磁盘读写IO延迟过大时将其自动标记为。Ut状态，以避免使用该性能差的磁盘，但需注意标记为OUt的单集群内磁盘存在上线值，该操作只可以进行1次，以避免将多个副本同时标记为。Ut或网络抖动导致大量磁盘被标记为OUt影响集群整体不可读写。同时，标记为。IIt后续尽快进行更换硬盘及数据重分布操作，防止此时集群内出现第二块满盘而该功能不可用。21、分布式存储是否需要备份？如果需要的话有哪些常用产品？备份的需求是基于数据重要性和系统稳定性。正常来说是需要备份的，即使分布式存储拥有多副本，保证一定的数据可恢复性。但是为了安全期间，防止整个系统的宕机，还是要备份的。备份的选择，主要考虑两个方面，一是分布式存储系统自身支持的备份恢复及双活，可以保证应用系统的稳定性。二是选择第三方备份软件。是否需要备份建议针对业务系统保存的数据重要性级别而定，如业务系统数据需进行本地、同城或异地备份，那么建议在应用端对需要备份的数据进行统一备份，存储端不进行备份，这样可保持整体备份架构统一性，避免备份大量无用数据造成备份设备容量浪费。应用端备份时可使用统一备份软件，如NBU、TSM等。依然需要备份，分布式存储的副本或纠删码是防止存储部件损坏造成数据丢失或业务暂停，哪怕分布式存储启用快照功能，也是无法防止物理故障。备份的意义在于使用与存储完全隔离的故障域来保护数据，分离的存储操作系统，不同的物理设备，不同的物理区域，以防止物理故障，逻辑故障。方式的话有：L备份软件+硬盘设备或磁带设备；4 .存储之间的复制；5 .以及现在新的存储至对象存储方式，其本质是存储自带备份小软件将属于备份到硬盘设备的方式。22、分布式存储节点超过内部通信交换机端口上限后，如何扩展内部通信交换机？业务量大时交换机节点间通信是否会受阻？需要扩容内部交换机，分布式存储的交换机扩展方式与业务交换机的扩展方式都是一致的，最好在网络架构规划时预留交换机在线扩展条件（包括交换机端口等），以避免停机扩容带来的存储不可用。23、如何做包括元数据在内的数据迁移？打个比方，大数据的Cloudera集群，由于是商业化产品，通常有高可用，namenode都是高可用的，所以，你如果要搬机房迁移的话，我们做过（这是一个悲剧，机房租用期到了），可以先迁移一个namenode,保证网络畅通（幸好是迁移到隔壁机房），再迁移另外一个，然后再迁移各个datanode,基本用户无感知。还是需要结合当前元数据的存储方式和数据迁移的目的综合考虑。24、Al训练或大数据分析是直接使用对象存储好，还是先把数据抽取到本地文件系统好？抽取到本地存储,这绝对不是一个好的主意，大数据平台的数据量十分庞大,所进行的操作涉及的数据，少则几个G,多达几十个T,如此多的数据，就算你本地存储够大，请问抽取传输要多少时间。所以，必定是在计算节点进行分析，可以的话，可以调用有GPU的计算节点进行AI训练。至于对象存储，是可以的，现在aws上大数据分析，有的就是基于对象存储。这个需要结合数据量的大小和本地文件系统和对象存储的访问性能来共同决定。如果数据量过大已经超出了本地文件系统的支持容量，那么就要使用对象存储。本地文件系统如果性能好很多，而数据又需要频繁读写，可以将数据预加载到本地以提升性能。25、分布式存储场景中是否也可基于AIops进行一些智能运维？有什么建议？在金融行业目前也有蛮多分布式存储集群案例，那基于存储所关心的集群存储服务故障自愈、磁盘故障的SMART预测是否也可以借鉴这套算法模型去设计？算法本身与数据是如何存储的并无直接关系，基于分布式存储的大数据平台正是机器学习、智能运维分析的奠基石，大量、丰富、有效的数据为算法分析提供了分析的可能。磁盘故障的分析需要首先观察磁盘历史数据的趋势及分布，选择相应算法可以实现有效的预测。故障自愈部分的建设需要结合专家建议，给出特定场景下故障自愈方案才可以落地实现。26、从运维的角度看，分布式存储设计时要考虑咖些方面？运维管理中的监控告警、备份恢复与异地容灾等应该如何规划？结合流行的ceph分布式做解释：（1）分布式存储监控:搭建分布式存储的开源软件通常都是服务器，是以服务器自有磁盘来做存储的，所以监控可以在服务器的磁盘上设置，同时.，我们同样可以用prometheus+grafana的方式进行监控，部署开源的ceph_exporter服务。（2）备份和恢复：分布式存储是不需要备份的，因为故障本身就在其软件设计的计划中，比如CePh,设置2至J3个mds+monitor,45个osd,坏了几个节点，可以从其他节点恢复。（3）异地灾备：比如CePh的RBD快照技术，通过差量文件的方式定期将数据备份到灾备中心，当主数据中心发生故障时，从灾备中心恢复最近的备份数据并重启相应的虚拟机，最大程度降低灾难时的数据恢复时间。在设计时应考虑到网络架构对性能的影响、监控内容的合理性、运维的便捷性等方面，监控告警主要为硬件类告警、操作系统告警、应用告警、性能容量告警几大类，针对备份恢复及异地容灾建议在应用客户端进行按需备份容灾。27、如果选择基于开源软件的分布式存储技术路线，如何做好运维人才队伍建设？如何做好软件产品平滑迭代？如何构建企业基于开源分布式存储系统的业务生态？对于人才建设：1、找一两名在其他公司有实际落地经验的带头人，最好在社区比较活跃，负责项目规划2、招聘几名应届实习生负责项目实施，这个过程一般会有新人脱颖而出对于产品迭代：只进行非常有必要的升级迭代，避免陷入无限升级的困境，同时在项目规划之初考虑升级迭代的方式，对于分布式系统，逐台升级一般不影响业务使用对于构建业务生态：由技术部架构选定场景，制定进相应技术规范中，并由开发、运维进行落实。28、CePh在海量小文件的环境下，稳定性和扩展性如何？海量小文件存储（简称LoSF,Iotsofsmanfiles）出现后，就一直是业界的难题，许多互联网公司也针对自己的具体场景研发了自己的存储方案，还有一些公司在现有开源项目基础上做针对性改造优化以满足业务存储需求；一、通过对若干分布式存储系统的调研、测试与使用，与其它分布式系统相比，海量小文件存储更侧重于解决两个问题：1、海量小文件的元数据信息组织与管理：对于百亿量级的数据，每个文件元信息按IoOB计算，元信息总数据量为1TB,远超过目前单机服务器内存大小;若使用本地持久化设备存储，须高效满足每次文件存取请求的元数据查询寻址（对于上层有Cdn的业务场景，可能不存在明显的数据热点），为了避免单点，还要有备用元数据节点；同时，单组元数据服务器也成为整个集群规模扩展的瓶颈;或者使用独立的存储集群存储管理元数据信息，当数据存储节点的状态发生变更时，应该及时通知相应元数据信息进行变更。对此问题，各分布式存储系统主要采用以下对策：1）设计时就在文件名中包含了部分元数据信息，减小了元数据规模，元数据节点只负责管理粒度更大的分片结构信息；2）通过升级优化硬件，使用分布式元数据架构一一多组（每组2台）10性能更好的ssd服务器一一存储集群的元数据信息，满足单次IO元数据查询的同时，也实现了元数据存储的扩展性；3）系统模块提供了图片逻辑卷到物理卷轴的映射存储与查询功能，通过cache集群来降低延时提高并发。2、本地磁盘文件的存储与管理（本地存储引擎）：对于常见的Linux文件系统,读取一个文件通常需要三次磁盘10（读取目录元数据到内存，把文件的inode节点装载到内存，最后读取实际的文件内容）；按目前主流2TB4TB的Sata盘，可存储2kw4kw个IOOKB大小的文件，由于文件数太多，无法将所有目录及文件的inode信息缓存到内存，很难实现每个图片读取只需要一次磁盘IO的理想状态，而长尾现象使得热点缓存无明显效果；当请求寻址到具体的一块磁盘，如何减少文件存取的io次数，高效地响应请求（尤其是读）已成为必须解决的另一问题。对此问题，有些系统采用了小文件合并存储+索引文件的优化方案，此方案有许多益处：a.合并后的合并大文件通常在64MB,甚至更大，单盘所存储的合并大文件数量远小于原小文件的数量，其inode等信息可以全部被cache到内存,减少了一次不必要的磁盘IO；b.索引文件通常数据量（通常只存储小文件所在的合并文件，及。ffset和SiZe等关键信息）很小，可以全部加载到内存中，读取时先访问内存索引数据，再根据合并文件、OffSet和SiZe访问实际文件数据，实现了一次磁盘Ic）的目的；c.单个小文件独立存储时，文件系统存储了其guid、属主、大小、创建日期、访问日期、访问权限及其它结构信息，有些信息可能不是业务所必需的，在合并存储时，可根据实际需要对文件元数据信息裁剪后在做合并，减少空间占用。除了合并方法外，还可以使用IO性能更好的SS