什么是一致性？至于原理什么的，这里就不赘述了，总的来说目前的分布式系统实现起来基本上都是基于BASE理论的，业务需要保持最终的一致性，说白了了是可以允许 中间过程的短暂不一致，只需要最后一致就好。一说到这个，很多人马上就能想到XA和TCC这两种分布式事务的实现，而且也有很多人针对这两种思想设计出了很好的实现，比如：tcc-lcn:https://github.com/codingapi/tx-lcn 还有很多的实现，去github上一搜就能找到。但是基于XA需要有强大的事务管理器来协调事务操作，TCC的方式需要第三方协调者，多一个中间件就多一分维护，同时业务难度也就上升很多 。当然如果公司中有非常牛逼的中间件团队这个就基本可以忽略了，基本能保持最少4个9的可靠性（https://blog.csdn.net/varyall/article/details/82592970）。B端业务场景通常业务系统B端非常重视一致性，C端则更加重视高可用，在B端数据配置的时候通常都是需要调用好几个系统才能完成一个数据的创建，如商品创建基本都需要创建商品基础数据创建凭证模板创建适用门店库创建xxx关联数据落本地数据在这里的每一步都可能会失败，比如网络超时，db抖动等等常见的失败原因。每一步失败都意味着整个流程需要重试（更恐怖的是有的业务需要回滚前面的步骤）。回滚基本不在业务考虑范围内，因为本来业务就是要做好创建的工作，而且在校验阶段都是符合创建条件的，那么业务上肯定是希望能够完整的建好业务数据，回滚只是作为非常规运维手段来使用。可以需要通过以下几个点来实现最终一致性.重试就像上面说的，在这种可重试的失败需要系统能够自动重试，重试的方法有很多，可以基于任何有定时任务功能的系统或框架来实行，如linux的crontabquartzschedulerxxxl-job等都符合重试的要求，处理业务的时候本地落一条流水数据，失败后设置可重试状态，等待定时任务来执行。注意：重试的时候记录好trace，这对排查问题非常有帮助需要考虑好幂等性需要考虑好并发重试次数幂等在任务进行重试执行的时候，如何保证重复执行的幂等性呢？ 首先：底层接口需要支持幂等，每次重试的时候业务流水id都保持一致，这样通过流水id来实现幂等，防止数据重复创建。但是如果底层接口不支持幂等呢？（这种肯定有的，反正有各种历史原因） 那么就需要业务自己来保证幂等了，在接口执行的时候落一条流水记录，执行完成后更新流水，在执行前先判断流水是否已经执行成功，如果成功了就幂等返回，不做业务操作。通过本地落流水只能保证99%以上幂等，如果完全依赖这个做幂等那就想的太简单了，思考下，如果在调用某个接口的时候返回了超时的异常，此时流水状态设置的还是失败状态，等待重试的时候还是会进行重复请求，这样还是会重复创建数据。所以如果底层不支持流水幂等，而是支持业务幂等的话，如创建的时候有相同的id则会查询一下本地DB，已经有数据就返回指定的错误码，那么业务上还可以根据这个错误码进行幂等处理。如果底层业务幂等都不支持，那这个就只能在处理的时候先查一次，再决定是否调用这个接口了（还是有风险的）。并发做好幂等其实还不够，还需要做好并发处理，比如我的业务在处理的时候如果失败了任务重复调度导致两个任务一起执行了，或者任务执行的时候手动触发了任务执行等，这些问题都是存在的。要做好并发处理，优先考虑使用分布式锁，在业务处理前先获取锁，获取锁失败则说明已经有任务在执行了，当前任务执行结束，等待之前的任务执行完成。加个分布式锁就可以了？ 那也还是想的太简单了，考虑下这个场景第一次用户编辑的时候，在执行第三步的时候网络超时失败了，落了重试任务，此时任务还没开始调度，用户又开始编辑数据，此时执行的时候获取到了锁，执行成功了。然后定时任务调度拉起之前重试的任务，继续执行第三步的操作，然后数据就被覆盖了。。。这时聪明的你已经想到了长锁+可重入锁的方式了：业务执行的时候先落一条长锁，只有执行成功的时候才会释放锁，同时通过请求id作为可重入的判断条件，业务失败后任务拉起来执行的时候还是相同的流水ID，这时任务是可以正常执行的。此时用户想要编辑数据，则会获取锁失败，用户无法进行编辑，此时给个友好的提示。这种方式还要注意一个点，分布式锁改为了分布式可重入锁，那么并发问题又来了，如果任务同时执行了都是相同的流水id，都能正常执行。 可以通过如下的方式来避免这个通过限制可重入个数为1在业务内部再加一个锁小结考虑好幂等，并发，重试这几个问题后，整个业务系统就可以非常健壮的跑起来了。那么问题来了，为什么只要重试而不需要做回滚呢？会进入任务执行的时候，需要基础校验都已经完成了，校验通过后说明数据是允许执行的，既然已经拿到了执行的门票，那么我们的任务就是要保证创建成功，至于回滚等操作只会在底层数据出现问题，无法执行完整的创建流程，需要回滚之前的操作。实际业务上使用的时候基本不会去写回滚的逻辑的，首先加重了开发的任务，其次回滚这种逻辑更适合作为运维手段来执行，这里可以考虑下原因哦。

为推进金融科技安全创新发展，金融科技产业联盟积极组织会员单位进行前瞻性研究，汇集研究成果及实践经验，形成《金融科技发展专报》，供监管部门和产业机构参考。当前，金融等重点行业都在进行数字化转型，而分布式数据库作为数据承载工具，为数字化转型提供了有力的支撑。分布式数据库近年来发展迅猛，在产品成熟度上有了很大提升，但在行业应用和生态建设上仍有很多挑战。本文分析了分布式数据库发展情况、分布式数据库应用的主要问题，从行业应用的角度给出了分布式数据库发展的建议。一、发展情况过去三十年，以金融业为代表的核心信息系统架构依托IOE（即IBM、Oracle、EMC）技术，构建了一套集中、专用、封闭的稳态技术体系。但是，随着互联网及云化时代的到来，企业业务架构产生巨大变化，以银行为代表的金融业需加速构建敏态体系，推动底层数据库的分布式改造和互联网金融业务创新。分布式数据库具有满足行业关键应用的高扩展性、高性能、高可用性及软硬件解耦等特性，是金融等重点行业信息系统数字化转型的基石。（一）产品成熟度提升随着分布式数据库在金融等重点行业的不断应用，产品成熟度得到很大提升。一是新技术的不断发展使得分布式数据库在自身固有的优势领域，如扩展性、高可用等方面进一步强化，已有多个应用在重点行业核心业务中落地。二是国产分布式数据库的性能已经实现了与其他商业数据库持平甚至超越，这在多个大型企业机构产品准入测试及业内国际基准测试（如在线交易场景TPCC、在线分析场景TPCH等）中得到充分证明，可对行业核心业务起到重要的支撑作用。三是更多厂商开始提供对主流国产分布式数据库的功能支持，产品的兼容性取得显著进展。管理控制软件、迁移工具等配套设施逐渐完善，极大地降低了数据库的使用门槛和迁移成本。（二）生态逐步完善一是加快推动分布式数据库在重点行业落地，主流分布式数据库厂商纷纷与众多大型银行、企业等开展联合创新活动，取得了许多突破性的成果。以某厂商的分布式数据库为例，在与大型商业银行的联创过程中，已完成10个以上业务系统的分布式数据库替换，覆盖银行A类到C类全场景业务。二是通过一站式的迁移解决方案，实现以较小的业务改造工作量从传统数据库向分布式数据库转型，迁移成本相对较低。而且使用分布式数据库后，业务系统运行稳定，可靠性和扩展性有所增强，从各项指标看，已基本具备承接Oracle及DB2大机下移的能力。三是分布式数据库相关的行业标准和评价体系逐步健全，对产品发展起到较强的规范引领作用。（三）总体发展情况向好当前国产分布式数据库已经渡过了“能用”阶段，正在迈向“好用、易用”阶段。横向来看，我国分布式数据库的发展基本与国际同步，tpcc、sysbench等性能指标和RTO、RPO等可靠性指标甚至具有优势，在应用领域取得些许领先。纵向来看，以金融业为例，分布式数据库应用取得较大进展，不管是在互联网新核心业务，还是传统核心业务中，分布式数据库行业应用落地数量大幅增加，有逐步替代集中式数据库的趋势。二、面临的主要问题（一）主体改造意愿不强，行业实践尚不充分一方面，原有数据库系统改造为分布式数据库，对用户及应用单位提出了较高的要求。改造所面临的成本问题，以及改造完成后分布式运维实施的复杂性，使得部分金融机构对于全面应用分布式还存在有一定的疑虑，主动改造意愿不强。另一方面，分布式数据库在行业典型应用场景中的落地仍处于摸索阶段。由于部分项目中存在一定的需求定制化，应用解决方案与产品的边界不够清晰，产品的规模化复制能力仍有待加强，行业最佳实践相对缺乏。这些因素也影响了金融机构对迁移采用分布式数据库技术的积极性。（二）分布式数据库的生态建设仍需加强生态建设是当前我国基础软件相对薄弱的一环，特别是对基于自研的分布式数据库厂商而言，虽然在实现技术和产品更加自主可控，但在生态建设方面仍需积极应对投入转化慢、门槛高、市场接受程度低等挑战。一方面，部分产品的技术体系相对封闭，用户无法从市场快速获取合格的开发运维人员，导致业务改造及生产运维仍严重依赖原厂，规模化复制效应较差。另一方面，部分产品的开放性仍有待提升，与其他平台数据互联互通的能力不足在客观上造成了业务“上车容易下车难”的现实困境，增加了用户被锁定的风险。（三）可持续发展的盈利模式需进一步探索我国数据库的发展可以追溯到30多年前，在这样一个相对较长的发展周期内，技术和产品都取得了显著进展，但在产业化方面，知识产权的保护不够充分等诸多问题造成部分参与主体的市场化盈利能力较弱，产业整体规模难以做大。分布式数据库虽然已取得了一定进展，但“池子深才能养大鱼”，如何依托当前政策窗口，真正形成可持续发展的商业模式，还需进一步探讨。三、行业的应用建议 尽管存在一些问题，但我们坚信分布式是数据库未来的发展趋势。如果将分布式数据库和单机数据库类比为“高铁”和“轿车”，因两者定位不同，期望“高铁”像“轿车”一样简单易用既不现实也不科学。所以应避免将分布式数据库的应用简单地理解为对单机或者集中式数据库的一对一替换，而要深入考虑如何充分发挥分布式数据库的技术优势。遵循以上思路，我们对于分布式数据库在金融等重点行业的应用提出以下几点建议：（一）通过技术创新和最佳实践，推动行业应用不断深入一方面，要探索利用人工智能等新技术提升产品服务效能。人工智能技术可实现自动数据分区规划、故障自动诊断和自愈、自动负载均衡、面向混合负载的自调优等功能。目前人工智能技术在分布式场景已经有了一些单点突破，但距离全场景落地、实现整体成本的全面降低还有很长的一段路要走，需要继续加以积极的行业引导，推进技术交流和产业落地。另一方面，需充分发挥好示范项目效应。在金融等重点行业典型应用场景如分布式架构设计、多地多中心容灾等，形成最佳解决方案，并在行业推广落地。在此过程中，提炼出更适合分布式数据库的开发、运维、硬件建设等相关要求，研究制定数据库开发、运维、应用方面的标准规范，提高行业的标准化水平，引导各参与主体规范应用分布式数据库，推进行业转型。同时应约束不必要的定制化需求，减少无序竞争，实现技术聚焦。（二）积极推动生态建设，发挥产业引领作用从软件发展历史看，生态建设是基础软件产业化的重要一环。任何一款商业上真正成功的软件产品，无一不是生态建设上获得广泛认可的成功案例。首先，充分发挥产业联盟桥梁纽带作用，推动产业发展。在行业内积极进行资源引流，逐步提升技术营运效率及影响力，搭建高端对话平台，促进分布式数据库应用方、应用开发方及厂商更好地交流，共同面对分布式转型下的业务及技术挑战，推进行业生态繁荣；加强与分布式中间件、分布式服务框架的合作与交流，通过开源、社区等形式建立广泛的赋能体系；鼓励应用软件厂商全面向分布式架构转型，建立相应的培训体系和检测认证体系。其次，完善技术生态，鼓励引入第三方软件垂直提供商。在运维管控、工具端以及解决方案层面实现更多差异化的平台能力，加厚行业整体的技术底盘；鼓励第三方产品服务化和上下游集成，推进各产品的互联互通，打造良好技术生态，促进行业健康发展。再次，建立基础软件开放生态体系，推动开源建设。应鼓励有研发实力的厂商基于国产开源数据库做发行商，有运维能力的厂商基于优质的国产数据库打造适用于自主可控要求的数据库解决方案。数据库厂商和合作伙伴应基于数据库代码开源、产品开放等形式，使数据库产业从封闭商业生态走向产业共赢的开放生态，共同打造开放的数据库生态体系。最后，进一步推进政产学研合作，加强人才储备。明确人才发展战略，梳理多层次行业人才资源地图。加强厂商与各科研院所合作，推进高校在包括数据库在内的基础软件方面专业投入，鼓励有条件的厂商和高校开展课程共建、实践共建，为联合推进分布式数据库关键技术在理论和实践层面的难点问题攻关储备智力资源。（三）全面拥抱云，开展行业可持续发展的尝试与探索数据库上云已逐步成为产业共识。根据Gartner的统计，到2021年，云数据库在整个数据库市场中的占比将首次达到50%；而到2023年，75%的数据库将会跑在云平台之上。发展云数据库，不仅是对技术和产品的重要升级，更是对数据库良性健康发展的商业模式有益探索，对于实现主体可控、支撑行业长期稳定发展具有重要的现实意义。分布式数据库与单机数据库不同，需要更大的集群规模才能实现资源的更有效利用。分布式数据库与云计算是天然伴生关系，通过云化部署，能够帮助分布式数据库扬长避短，充分发挥分布式数据库在扩展性、资源调度方面的灵活性和优势，在提升资源利用效率同时，显著降低运维成本，实现真正业务价值。一是云化基础设施可以通过智能调度、运维系统高效管理更为丰富的应用，并通过多云及边缘计算将应用扩展到多种场景中。二是软硬协同可为应用提供更好的性能，提升应用隔离性等。三是云数据库和云基础设施结合，如利用云基础设施本身的能力实现数据库的跨数据中心访问等，可使存储具备理解、预处理数据库语义的能力。 基于以上，一是建议扩大云数据库在金融行业的应用规模。云数据库已经在互联网、电子政务等各行业得到了广泛应用，在金融行业的应用及推广也在稳步推进中。应引导重点用户单位与厂商尝试在行业落地云数据库及云平台，鼓励技术共创，共同探索基于现代云平台的分布式数据库运维及业务开发体系。二是建议推进行业云发展以提高行业标准化程度。在满足合规营运的前提下，应实现底层基础设施共享，降低中小用户对于分布式数据库的使用门槛和人才需求，减少重复投资，实现集约化营运，充分发挥分布式数据库的规模化优势。厘清各参与主体运营职责与边界，依托业内现有的成熟云平台技术，形成一个或若干个云技术底座，鼓励传统非云数据库厂商根据自身产品技术特点完成与云平台的对接，最终形成行业的云上产品集市，逐步简化并统一运维及交付界面，降低行业应用门槛，提高行业标准化程度。 来源：发展研究部

如题？

【功能模块】分布式保存的模型转存【操作步骤&问题现象】1、前提：代码修改自PanGu-Alpha，训练中是采用了数据并行、模型并行，并开启了优化器并行，因此所有保存的CheckPoint才是一个完整的模型。我们想把这些ckpt合并成一个完整的权重文件。2、我们看到官方文档会有一份合并示例，但是盘古模型似乎用不了这种方法，见下图1。如果将 load_checkpoint 和load_param_into_net改为load_distributed_checkpoint，等模型加载完参数后，再获取权重的值并保存，能得到一份完整的权重文件吗？3、另外一个更好的方向是，我能通过读取strategy.ckpt，手动合并CheckPoint吗？那么parallel_layouts里面的参数该怎样理解？见注释2。【截图信息】图 1：注释 2：param_name: "backbone.blocks.1.attention.dense1.weight"parallel_layouts { dev_matrix { dim: 4 dim: 2 } tensor_map { dim: 0 dim: -1 } param_split_shape { } indices_offset { } field: 0 opt_weight_shard_step: 2 opt_weight_shard_size: -1}

  目前，金融行业的变化已经深入影响到每个人的日常生活，从大家习以为常的移动支付，到正在进化中的数字货币、无实体银行等，人们的金融消费习惯正在被数字技术所改变。金融科技作为商业银行高质量发展及数字化转型的重要驱动力，深刻改变了银行业的经营模式，云计算、人工智能、大数据、5G和区块链等新技术的出现，将为银行的未来发展提供更多可能。早在2018年，中国银行（简称中行）就发布了《科技引领数字化发展战略》，将科技引领数字化发展置于新一期战略规划之首，以加快打造用户体验极致、场景生态丰富、线上线下协同、产品创新灵活、运营管理高效、风险控制智能的数字化银行。这一时期，金融科技背后IT基础设施的重要性日益凸显，前端需要提供的数字化、个性化服务越多，对后端的计算能力、稳定性与灵活性要求就越高。基于此，通过全面云化和分布式架构，实现主机下移等金融IT基础设施的重构，就成为中行实现未来发展的必由之路。深化科技改革，坚定开启生产系统新一代存储网络建设随着金融业务的不断深化，金融科技在经历了电子化、网络化之后，逐步迈入数字化、智能化发展的新阶段。在金融全面数字化、智能化的新时代，金融IT基础设施的科技改革，不仅聚焦于金融云、大数据、AI等热点技术的投入，也对核心账务联机交易业务等传统生产系统的基础设施，提出了自我建设与求新求变的新需求。高速稳定的业务数据存储及同城数据实时容灾备份一直是金融IT生产系统中高可用的关键场景，中行在通盘梳理了IT基础设施架构后，敏锐识别出金融生产系统中基于FC（Fibre Channel光纤通道协议）封闭技术的传统数据存储已进入变革的窗口期，因此，在银行业内率先开启了新一代存储网络的创新建设。新一代存储网络的创新研究主要受益于以下三方面的变革驱动：首先，业务增长驱动了存储网络的变革。2020年前9个月，中行在保持对公客户数量持续稳步增长的同时，普惠型小微企业贷款及个人金融等业务均取得了可观的增长，业务覆盖全球62个国家和地区，手机银行等线上交易业务快速发展。这主要得益于中行深化了科技与业务的融合，强化了科技对业务发展的赋能作用，也显示出中行经营模式的变化。业务变化的背后是计算及存储服务器指数级的增长和各类交易系统数据TB级网络流量的增长。数据显示，中行业务系统同城数据的日均备份量已由2018年的500TB提高到2020年的PB级，连续三年年均增长超30%。中行基于分布式架构的“多地多中心”数据中心布局及海量数据在中心内、中心间的高速交互，均使当前以FC-SAN 8/16G为主流速率的存储网络面临巨大挑战。其次，技术发展驱动了存储网络的变革。技术发展包含存储介质及存储协议两个方面。目前，存储介质已从机械硬盘（HDD）发展到固态存储（SSD），全方位提升了网络的存储性能：包括IOPS每秒读写能力提升了100倍，时延从2ms到0.2ms降低了10倍，年失效率降低5倍，能耗降低了87%等等。存储介质性能的百倍提升，驱动了存储协议从传统串行SCSI协议发展到高速并行的NVMe协议。为了保证全闪存NVMe协议高吞吐、低时延的特性，在远程直接存储读取（RDMA）场景下，新一代存储网络需满足零丢包、低时延及高吞吐的要求。最后，简化管理驱动了存储网络的变革。金融IT基础设施全面云化的发展趋势已势不可挡，目前，互联网金融、移动金融、大数据分析等业务均已实现了云化，而联机交易等核心业务因FC-SAN存储网络的系统及协议较为独立，因此在业务灵活上云及大规模自动化部署、管理方面，不仅实现复杂，难度大，且运维成本也较高。同时，由于同城跨DC数百条8G/16G FC链路占用了昂贵的波分传输通道，也进一步提升了成本。此外，FC-SAN技术较封闭，全球仅有两家美国公司可以提供相关产品，不仅采购来源单一，建设维护成本较高，更难以保障关键生产系统自主可控的要求。业界首个新一代智能无损存储网络，为生产系统带来三大升级中行“RoCE-SAN”是业界首个基于标准以太IP网及开放的RoCE（以太网远程内存访问）协议打造的新一代智能无损存储网络。如图1所示，新一代智能无损存储网络“RoCE-SAN”采用华为CloudEngine数据中心交换机和OceanStore Dorado全闪存架构，结合中行具体的应用场景，实现了智能缓存管理、逐流精准控速、故障高可用秒级切换的技术创新突破，满足了金融企业对高可用存储网络的需求。图1 新一代智能无损存储网络整体架构2020年11月20日，基于“RoCE-SAN”架构的应用项目管理平台及应急运维管理平台的成功投产上线，标志着中行自主可控的新一代无损存储网络正式投入生产运行。新一代智能无损存储网络为中行的联机交易等生产系统带来了三大升级：第一， 高性能、高可靠。首先，新一代智能无损存储网络实现了25GE接入、100GE上行，同时具备100GE接入、400GE上行的平滑演进能力。网络容量大、带宽足，可充分发挥全闪存百万级IOPS的优势，以满足未来存储数据容量PB级发展的需求。同时，新一代存储网络突破了以太网超长距传输反馈慢的缺陷，不仅可实现跨数据中心间（＞50KM）的长距无损传输，且通过智能算法提升了数据中心间专线带宽的利用率，降低了使用成本。在相同场景下，对比FC-SAN，新存储系统的整体吞吐性能最大可实现85%的提升（见图2）。图2 RoCE与FC的效能对比其次，新一代智能无损存储网络可充分发挥网络的流量智能识别、主动差异化控制等价值，在拥塞场景下拥有更大的带宽利用率及更低的平均时延，与FC-SAN相比，其最高可将流量突发导致的拥塞时延降低50%（见图3）。 图3 256KB数据块时延变化最后，在网络故障的场景下，交换机可快速感知主机、存储及网络的状态变化，并通报主机进行多路径切换，使端到端的切换时间小于1秒，确保了系统的高可靠。第二， 自主可控，开放生态。新一代智能无损存储网络采用通用以太网交换机构建，基于IP和RoCE通用存储网络协议运行，不仅有效提升了核心生产系统存储网络的标准化及开放性，更进一步提升了核心生产业务自主可控的能力。此外，新一代智能无损存储网络能够与业界主流的OS进行协同对接，可基于标准开放的API与更多第三方伙伴共建场景化服务，共同打造生态圈。第三，灵活上云。新一代智能无损存储网络可实现数据中心内SAN网络与普通业务场景LAN网络的无缝对接及混流运行，在将存储服务器云化的同时，降低了管理的复杂度和运维成本，提升了整个IT基础设施的自动化水平和业务敏捷性。同时，新一代智能无损存储网络可提供100G接入/400G转发的高性能组网，以有效满足分布式架构云平台下数万台存储服务器的大规模部署。未来，中行将按照“稳定可靠、智能高效”的原则持续推进新一代智能无损存储网络的能力建设，通过异地长距传输、数据在线压缩等能力的构建，支撑中行“多地多中心”打造完整的数据容灾系统。运用新科技，打造新时代全球一流银行在众多业内人士看来，目前，我们正在步入“洞见力时代”，如同柏拉图《理想国》 中的洞穴隐喻所昭示的那样，只有坚持走出原有舒适区，才能发现崭新天地。中行以数字化银行为主轴、以金融科技为抓手，打造的新一代“RoCE-SAN”智能无损存储网络目前已初现成效，鉴于新一代智能无损存储网络属于全新的技术领域，因此，虽然中行已跨出了艰难的一步，但后面的路还很长，还需要不断探索总结，一步一个脚印地持续建设和完善。新一代智能无损存储网络是中国银行敢为天下先，面向未来发展取得的一项重大突破，也是对金融行业存储网络建设的又一次创新和探索，该系统的成功搭建，为整个金融业、银行业的IT架构发展演变提供了准确、详实的路径参考。中行将在此基础上夯实金融业务系统的数据底座，在支撑智能化、数字化的建设和转型的同时，持续建设新时代的全球一流银行！

此贴是用户的一个提问的经验帖子，在此做下案例分析。帖子来源见： https://bbs.huaweicloud.com/forum/thread-163409-1-1.html ## 问题 1、在容器中启动训练的时候，如何指定通信端口？ 2.如何进入到容器中并且在进入一个conda环境中呢，应该如何操作？ ## 回复 ### 问题1： mpirun 可以通过 -mca 参数中传入容器的端口号 port，具体如下图所示  注意：容器的端口号必须和主机共用端口号，即在docker run 后面加上--network host参数， 然后将 /etc/.ssh/sshd_config中的port修改为自己想设置的端口号（必须修改，不能是默认的22，不然和会和主机端口号冲突） ### 问题2： 进入conda环境的话可以通过修改 容器中的~/.bashrc中加入 conda activate

三个mon节点配置，重启1个mon节点观察现象：mon部署到node1,node2,client1上 ， client1没有OSD重启mon.client1,查看集群状态，可见 1/3 mons down, quorum node1,node2 告警等待复位的mon节点重新启动完成，查询状态恢复健康：vdbench业务流量也不受影响，未观察到明显波动； 剩余2个mon节点时，集群有告警，但功能与性能正常三个mon节点配置，重启2个mon节点验证：mon节点与OSD分开部署：（mon on node1 client1 client3三台服务器）重启2个mon节点此时VDbench压力不受影响，但是命令会卡住（只有1个mon节点），启动后，集群恢复健康，可正常执行命令：vdbench业务流量，未观察到明显变化，没有影响流量，但1个mon节点已经影响了命令执行，mon恢复后，集群恢复正常所以至少要有2个mon节点正常工作

验证触发mgr主备切换时，对集群性能是否有影响先给集群打上背景流量：ceph -s状态：停掉node3的mgr(active mgr)服务：systemctl stop ceph-mgr@node3ceph -s 观察，完成mgr@node3到mgr@node1的倒换，集群健康状态正常，client流量无明显波动。

通过手动触发的方式去验证scrub能力：找一个OSD目录：ls /var/lib/ceph/osd/ceph-5/current/pg 121.e9 删掉一个文件：手动执行：ceph pg scrub 121.e9检测结果：手动执行修复ceph pg repair 121.e9连续监控 ceph -s 状态，从 ERR变为OK

组件介绍CephCeph 是一个专注于分布式的、弹性可扩展的、高可靠的、性能优异的存储系统平台，可以同时支持块设备、文件系统和对象网关三种类型的存储接口。本文介绍的调优手段包括硬件层面和软件配置层面的优化，暂不涉及软件源码层面的优化。通过调整系统和Ceph配置参数，Ceph可以更充分的发挥系统硬件性能。Ceph PG分布调优和OSD绑核旨在让磁盘负载更平均，避免个别OSD成为瓶颈。此外，均衡型场景下，用NVMe SSD做Bcache也可以提升性能。Ceph架构如图1所示。图1 Ceph架构Ceph的模块及组件说明如表1所示。表1 模块说明模块名称功能描述RADOSRADOS（Reliable Autonomic Distributed Object Store，RADOS）是Ceph存储集群的基础。Ceph中的一切都以对象的形式存储，而RADOS就负责存储这些对象，而不考虑它们的数据类型。RADOS层确保数据一致性和可靠性。对于数据一致性，它执行数据复制、故障检测和恢复，还包括数据在集群节点间的recovery。OSD实际存储数据的进程。通常一个OSD daemon绑定一个物理磁盘。Client write/read数据最终都会走到OSD去执行write/read操作。MONMonitor在Ceph集群中扮演者管理者的角色，维护了整个集群的状态，是Ceph集群中最重要的组件。MON保证集群的相关组件在同一时刻能够达成一致，相当于集群的领导层，负责收集、更新和发布集群信息。为了规避单点故障，在实际的Ceph部署环境中会部署多个MON，同样会引来多个MON之前如何协同工作的问题。MGRMGR目前的主要功能是一个监控系统，包含采集、存储、分析（包含报警）和可视化几部分，用于把集群的一些指标暴露给外界使用。Librados简化访问RADOS的一种方法，目前支持PHP、Ruby、Java、Python、C和C++语言。它提供了Ceph存储集群的一个本地接口RADOS，并且是其他服务（如RBD、RGW）的基础，此外，还为CephFS提供POSIX接口。Librados API支持直接访问RADOS，使开发者能够创建自己的接口来访问Ceph集群存储。RBDCeph块设备，对外提供块存储。可以像磁盘一样被映射、格式化和挂载到服务器上。RGWCeph对象网关，提供了一个兼容S3和Swift的RESTful API接口。RGW还支持多租户和OpenStack的Keystone身份验证服务。MDSCeph元数据服务器，跟踪文件层次结构并存储只供CephFS使用的元数据。Ceph块设备和RADOS网关不需要元数据。MDS不直接给Client提供数据服务。CephFS提供了一个任意大小且兼容POSlX的分布式文件系统。CephFS依赖Ceph MDS来跟踪文件层次结构，即元数据。VdbenchVdbench是一个命令行实用程序，旨在帮助工程师和客户生成用于验证存储性能和存储数据完整性的磁盘IO负载。还可通过输入文本文件指定Vdbench 执行参数。Vdbench工具参数很多，表2列举了几个重要的常用参数。表2 常用参数配置项说明-f指定一个压力测试的脚本文件-o指定输出报告的路径，默认是当前路径lun测试的LUN设备或文件size设置测试LUN或测试文件的大小rdpct读所占百分比，100表示全读，0表示全写seekpct随机数据所占百分比，100代表全随机，0代表顺序elapsed定义本次运行测试时间环境介绍物理组网Ceph块设备物理环境采用“两层网络+三节点”的部署方案，其中，MON、MGR、MDS节点与OSD存储节点混合部署。在网络层面，Public网络与Cluster网络分离，两者均采用25GE光口来进行网络间的通信。物理组网如图1所示。图1 物理组网硬件配置Ceph所使用的环境如表1所示。表1 硬件配置服务器名称TaiShan 200服务器（型号2280）处理器鲲鹏920 5230处理器核数2*32核主频2600MHz内存大小12*16GB内存频率2666MHz（8*Micron 2R）网卡IN200网卡4*25GE硬盘系统盘：RAID1（2*960GB SATA SSD）均衡型配置数据盘：RAID模式下使能JBOD（12*4TB SATA HDD）NVMe SSD均衡性配置加速盘：1*ES3600P V5 3.2TB NVMe SSD高性能配置数据盘：12*ES3600P V5 3.2TB NVMe SSDRAID卡Avago SAS 3508软件版本使用到的相关软件版本如表2所示。表2 软件版本软件版本OSCentOS Linux release 7.6.1810openEuler 20.03 LTS SP1Ceph14.2.x Nautilusceph-deploy2.0.1Vdbench5.04.06节点信息主机的IP网段规划信息如表3所示。表3 节点信息主机类型主机名称Public 网段Cluster 网段OSD/MON节点node1192.168.3.0/24192.168.4.0/24OSD/MGR节点node2192.168.3.0/24192.168.4.0/24OSD/MDS节点node3192.168.3.0/24192.168.4.0/24组件部署对于Ceph块设备集群，其相关服务组件部署方式如表4所示。表4 组件部署物理机名称OSDMONMGRnode112*OSD1*MON1*MGRnode212*OSD1*MON1*MGRnode312*OSD1*MON1*MGR集群检查可以输入ceph health查看集群健康状态，显示HEALTH_OK表示集群正常。调优原则与思路块存储调优主要分为：均衡型配置调优以机械硬盘（HDD）作为数据盘，并配置适量固态硬盘（SSD）作为DB/WAL分区、元数据存储池的场景。高性能配置调优即所有数据盘都是用固态硬盘（SSD）的场景。请根据实际场景选择一种配置进行调优。调优原则在性能优化时，需要遵循一定的原则，主要有以下几个方面：对性能进行分析时，要多方面分析系统的资源瓶颈所在，如CPU利用率达到100%时，也可能是内存容量限制，导致CPU忙于处理内存调度。一次只对一个性能指标参数进行调整。分析工具本身运行可能会带来资源损耗，导致系统某方面的资源瓶颈情况更加严重，应避免或降低对应用程序的影响。调优思路调优分析思路如下：很多情况下压测流量并没有完全进入到后端（服务端），在网络接入层（云化的架构，比如：SLB/WAF/高防IP，甚至是CDN/全站加速等）可能就会出现由于各种规格（带宽、最大连接数、新建连接数等）限制或者因为压测的某些特征符合CC和DDoS的行为而触发了防护策略导致压测结果达不到预期。接着看关键指标是否满足要求，如果不满足，需要确定是哪个地方有问题，一般情况下，服务器端问题可能性比较大，也有可能是客户端问题（这种可能性非常小）。对于服务器端问题，需要定位的是硬件相关指标，例如CPU，Memory，Disk IO，Network IO，如果是某个硬件指标有问题，需要深入的进行分析。如果硬件指标都没有问题，需要查看中间件相关指标，例如：线程池、连接池、GC等，如果是这些指标问题，需要深入的分析。如果中间件相关指标没问题，需要查看数据库相关指标，例如：慢查SQL，命中率，锁、参数设置。如果以上指标都正常，应用程序的算法、缓冲、缓存、同步或异步可能有问题，需要具体深入的分析。可能的瓶颈点如表1所示。表1 可能的瓶颈点瓶颈点说明硬件/规格一般指的是CPU、内存、磁盘IO方面的问题，分为服务器硬件瓶颈、网络瓶颈（对局域网可以不考虑）。中间件一般指的是应用服务器、web服务器等应用软件，还包括数据库系统。例如：中间件weblogic平台上配置的JDBC连接池的参数设置不合理，造成的瓶颈。应用程序一般指的是开发人员开发出来的应用程序。例如，JVM参数不合理，容器配置不合理，慢SQL，数据库设计不合理，程序架构规划不合理，程序本身设计有问题（串行处理、请求的处理线程不够、无缓冲、无缓存、生产者和消费者不协调等），造成系统在大量用户方位时性能低下而造成的瓶颈。操作系统一般指的是Windows、UNIX、Linux等操作系统。例如，在进行性能测试，出现物理内存不足时，虚拟内存设置也不合理，虚拟内存的交换效率就会大大降低，从而导致行为的响应时间大大增加，这时认为操作系统上出现性能瓶颈。网络设备一般指的是防火墙、动态负载均衡器、交换机等设备。当前更多的云化服务架构使用的网络接入产品：包括但不限于SLB/WAF/高防IP/CDN/全站加速等等。例如，在动态负载均衡器上设置了动态分发负载的机制，当发现某个应用服务器上的硬件资源已经到达极限时，动态负载均衡器将后续的交易请求发送到其他负载较轻的应用服务器上。在测试时发现，动态负载均衡器没有起到相应的作用，这时可以认为网络瓶颈。调优的通用步骤：调优通用步骤如图1所示。图1 调优通用步骤均衡型配置调优1. 硬件调优：硬件调优_鲲鹏BoostKit分布式存储使能套件_调优指南_Ceph块存储 调优指南_均衡型配置调优_华为云 (huaweicloud.com)2. 系统调优： 系统调优_鲲鹏BoostKit分布式存储使能套件_调优指南_Ceph块存储 调优指南_均衡型配置调优_华为云 (huaweicloud.com)3. ceph调优：  Ceph调优_鲲鹏BoostKit分布式存储使能套件_调优指南_Ceph块存储 调优指南_均衡型配置调优_华为云 (huaweicloud.com)4.  KAE zlib压缩调优： KAE zlib压缩调优_鲲鹏BoostKit分布式存储使能套件_调优指南_Ceph块存储 调优指南_均衡型配置调优_华为云 (huaweicloud.com)高性能配置调优1. 硬件调优高性能配置调优目的保证两个CPU负载较为均衡。方法将NVMe SSD与网卡均衡地插在两个CPU上。硬件类型优化项备注网卡NUMA资源均衡例如将板载网卡插到CPU1所属的PCIe槽位，将Mellanox CX4插到CPU2所属的PCIe槽位，使两个CPU负载较为均衡存储NUMA资源均衡例如将其中6*NVMe SSD插到CPU1所属的PCIe槽位，将另外6*NVMe SSD插到CPU2所属的PCIe槽位，使两个CPU负载较为均衡2. 系统调优OS配置调优目的调整系统配置选项，充分发挥系统硬件性能。方法具体优化项详见表1。表1 OS配置参数参数名称参数含义优化建议配置方法vm.swappinessswap为系统虚拟内存，使用虚拟内存会导致性能下降，应避免使用。默认值：60现象：用到swap时性能明显下降修改建议：关闭swap内存的使用，将该参数设定为0执行命令：sudo sysctl vm.swappiness=0 MTU网卡所能通过的最大数据包的大小，调大后可以减少网络包的数量以提高效率。默认值：1500 Bytes现象：可以通过ip addr命令查看修改建议：网卡所能通过的最大数据包的大小设置为9000 Bytes执行命令：vi /etc/sysconfig/network-scripts/ifcfg-$(Interface) 并增加MTU="9000"说明：${Interface}为网口名称。完成后重启网络服务。service network restartpid_max系统默认的“pid_max”值为32768，正常情况下是够用的，但跑重量任务时会出现不够用的情况，最终导致内存无法分配的错误。默认值：32768现象：通过cat /proc/sys/kernel/pid_max查看修改建议：设置系统可生成最大线程数为4194303执行命令：echo 4194303 > /proc/sys/kernel/pid_maxfile_max“file-max”是设置系统所有进程一共可以打开的文件数量。同时一些程序可以通过setrlimit调用，设置每个进程的限制。如果得到大量使用完文件句柄的错误信息，则应该增加这个值。默认值：13291808现象：通过cat /proc/sys/fs/file-max查看修改建议：设置系统所有进程一共可以打开的文件数量，设置为cat /proc/meminfo | grep MemTotal | awk '{print $2}'所查看到的值执行命令：echo ${file-max} > /proc/sys/fs/file-max说明：${file-max}为cat /proc/meminfo | grep MemTotal | awk '{print $2}' 所查看到的值。read_aheadLinux的文件预读readahead，指Linux系统内核将指定文件的某区域预读进页缓存起来，便于接下来对该区域进行读取时，不会因缺页（page fault）而阻塞。鉴于从内存读取比从磁盘读取要快很多，预读可以有效的减少磁盘的寻道次数和应用程序的IO等待时间，是改进磁盘读IO性能的重要优化手段之一。默认值：128 KB现象：预读可以有效的减少磁盘的寻道次数和应用程序的IO等待时间。通过/sbin/blockdev --getra /dev/sdb查看修改建议：通过数据预读并且记载到随机访问内存方式提高磁盘读操作，调整为8192 KB执行命令：/sbin/blockdev --setra /dev/sdb说明：此处以“/dev/sdb”为例，对所有服务器上的所有数据盘都要修改。I/O_SchedulerLinux IO调度器是Linux内核中的一个组成部分，用户可以通过调整这个调度器来优化系统性能。默认值：CFQ现象：要根据不同的存储器来设置Linux IO调度器从而达到优化系统性能修改建议：IO调度策略，HDD设置为deadline，SSD设置为noop执行命令：echo deadline > /sys/block/sdb/queue/scheduler说明：此处以“/dev/sdb”为例，对所有服务器上的所有数据盘都要修改。nr_requests在Linux系统中，如果有大量读请求，默认的请求队列或许应付不过来，Linux可以动态调整请求队列数，默认的请求队列数存放在“/sys/block/hda/queue/nr_requests”文件中默认值：128现象：通过适当的调整nr_requests参数可以提升磁盘的吞吐量修改建议：调整硬盘请求队列数，设置为512执行命令：echo 512 > /sys/block/sdb/queue/nr_requests说明：此处以“/dev/sdb”为例，对所有服务器上的所有数据盘都要修改。NUMA亲和优化方法保证网络和存储资源均衡地分配到各个NUMA节点。目的此处以12块NVMe SSD和4个网口为例，均衡分配到4个NUMA节点。NVMe SSD编号0~11，网口名为enps0f0,enps0f1,enps0f2,enps0f3。for i in {0..11}; do echo `expr ${i} / 3` > /sys/class/block/nvme${i}n1/device/device/numa_node; done for j in {0..3}; do echo ${j} > /sys/class/net/enps0f${j}/device/numa_node; done3. Ceph调优Ceph配置调优目的调整Ceph配置选项，充分发挥系统硬件性能。方法所有的ceph配置参数都是通过修改“/etc/ceph/ceph.conf”实现的。以上操作只是对当前Ceph节点生效，需要修改所有Ceph节点的“ceph.conf”文件并重启Ceph守护进程才对整个Ceph集群生效。表1 Ceph参数配置参数名称参数含义优化建议[global]osd_pool_default_min_sizePG处于degraded状态不影响其IO能力,min_size是一个PG能接受IO的最小副本数。默认值：0修改建议：1cluster_network配置一层不同于public network的网段，用于OSD间副本复制/数据均衡，缓解public network网络压力。默认值：/修改建议：192.168.4.0/24osd_pool_default_size副本数设置。默认值：3修改建议：3mon_max_pg_per_osd阈值项：调大PG告警阈值默认值：250修改建议：3000mon_max_pool_pg_num阈值项：调大PG告警阈值默认值：65536修改建议：300000debug_none关闭debug开关，减少日志打印开销修改建议：0/0debug_lockdepdebug_contextdebug_crushdebug_mdsdebug_mds_balancerdebug_mds_lockerdebug_mds_logdebug_mds_log_expiredebug_mds_migratordebug_bufferdebug_timerdebug_filerdebug_striperdebug_objecterdebug_radosdebug_rbddebug_rbd_mirrordebug_rbd_replaydebug_journalerdebug_objectcacherdebug_clientdebug_osddebug_optrackerdebug_objclassdebug_filestoredebug_journaldebug_msdebug_mondebug_moncdebug_paxosdebug_tpdebug_authdebug_cryptodebug_finisherdebug_reserverdebug_heartbeatmapdebug_perfcounterdebug_rgwdebug_civetwebdebug_javaclientdebug_asokdebug_throttledebug_refsdebug_xiodebug_compressordebug_bluestoredebug_bluefsdebug_bdevdebug_kstoredebug_rocksdbdebug_leveldbdebug_memdbdebug_kineticdebug_fusedebug_mgrdebug_mgrcdebug_dpdkdebug_eventtracethrottler_perf_counter默认开启，可以观察阈值是否达到瓶颈。性能调节到最佳后，建议关闭，tracker影响性能默认值：True修改建议：Falsems_dispatch_throttle_bytes等待调度的最大消息数，建议调大，提高消息处理效率默认值：104857600修改建议：2097152000ms_bind_before_connect消息队列绑定，保证多网口流量均衡默认值：False修改建议：True[client]rbd_cache关闭客户端cache。关闭后rbd cache一直是writethrough模式默认值：True修改建议：False[osd]osd_max_write_sizeOSD一次可写入的最大值（MB）默认值：90修改建议：256osd_client_message_size_cap客户端允许在内存中的最大数据（Bytes）默认值：524288000修改建议：1073741824osd_map_cache_size保留OSD Map的缓存（MB）默认值：50修改建议：1024bluestore_rocksdb_optionsrocksdb配置参数默认值： compression=kNoCompression,max_write_buffer_number=4,min_write_buffer_number_to_merge=1,recycle_log_file_num=4,write_buffer_size=268435456,writable_file_max_buffer_size=0,compaction_readahead_size=2097152,max_background_compactions=2 修改建议：compression=kNoCompression,max_write_buffer_number=64,min_write_buffer_number_to_merge=32,recycle_log_file_num=64,compaction_style=kCompactionStyleLevel,write_buffer_size=4MB,target_file_size_base=4MB,max_background_compactions=16,level0_file_num_compaction_trigger=64,level0_slowdown_writes_trigger=128,level0_stop_writes_trigger=256,max_bytes_for_level_base=6GB,compaction_threads=8,flusher_threads=4,compaction_readahead_size=2MBbluestore_csum_type不指定checksum type类型默认值：crc32c修改建议：nonemon_osd_full_ratio将OSD视为已满之前使用的磁盘空间的百分比。数据量超过这个百分比后会停止一切读写操作，直到扩容或清除数据量至小于该百分比默认值：0.95修改建议：0.97mon_osd_nearfull_ratio将OSD视为近似之前使用的磁盘空间的百分比。数据量超过这个百分比后会产生告警，提示空间即将耗尽默认值：0.85修改建议：0.95osd_min_pg_log_entriesPGLog记录条数下阈值默认值：3000修改建议：10osd_max_pg_log_entriesPGLog记录条数上阈值默认值：3000修改建议：10bluestore_cache_meta_ratiobluestore cache中分配给meta的比例默认值：0.4修改建议：0.8bluestore_cache_kv_ratiobluestore cache中分配给kv的比例默认值：0.4修改建议：0.2具体优化项详见表1。比方说要修改默认副本数为4，则在“/etc/ceph/ceph.conf”文件中添加“osd_pool_default_size = 4”这一行字段，然后systemctl restart ceph.target重启Ceph守护进程使之生效。PG分布调优目的调整每个OSD上承载的PG数量，使每个OSD的负载更加均衡。方法Ceph默认为每个存储池分配8个“pg/pgp”，在创建存储池的时候使用ceph osd pool create {pool-name} {pg-num} {pgp-num}指定“pg/pgp”数量，或者使用ceph osd pool set {pool_name} pg_num {pg-num}和ceph osd pool set {pool_name} pgp_num {pgp-num}修改已创建好的存储池的“pg/pgp”数量。修改完成后使用ceph osd pool get {pool_name} pg_num/pgp_num查看存储池的“pg/pgp”数量。PG分布参数配置如表2所示：说明：每个OSD上承载的PG数量应相同或非常接近，否则容易出现个别OSD压力较大成为瓶颈，运用balancer插件可以实现PG分布优化，可通过ceph balancer eval或ceph pg dump随时查看当前PG分布情况。通过ceph balancer mode upmap以及ceph balancer on使Ceph PG自动均衡优化，Ceph每隔60秒会调整少量PG分布。通过ceph balancer eval或ceph pg dump随时查看当前PG分布情况，若PG分布情况不再变化，则说明分布已达到最佳。上述每个OSD对应的PG分布主要影响写入的负载均衡。除了每个OSD对应的PG数量优化外，主PG的分布情况也需要视情况优化，即尽可能地将主PG均匀分布到各个OSD上。表2 PG分布参数配置参数名称参数说明优化建议pg_numTotal PGs = (Total_number_of_OSD * 100) / max_replication_count，得出的结果向上取到最近的2的整数次幂。默认值：8现象：pg数量太少的话会有warning提示修改建议：根据计算公式具体计算得到的值pgp_numpgp数量设置为与pg相同。默认值：8现象：pgp数量建议与pg数量相同修改建议：根据计算公式具体计算得到的值ceph_balancer_mode使能balancer均衡器插件，并设置均衡器插件模式为“upmap”。默认值：none现象：若PG数量不均衡会出现个别OSD负载较大而成为瓶颈修改建议：upmap“ceph balancer mode”默认为“none”，用ceph balancer mode upmap命令调整为“upmap”。“ceph balancer”功能默认不打开，ceph balancer on/off用来打开/关闭“ceph balancer”功能。OSD绑核目的建议将OSD进程绑定到固定CPU上。方法通过修改“/etc/ceph/ceph.conf”文件，添加“osd_numa_node = <NUM>”即可。表3 OSD绑核参数配置参数名称参数说明优化建议[osd.n]osd_numa_node将osd.n守护进程绑定到指定空闲NUMA节点上，此处的空闲NUMA节点指处理网卡软中断的节点以外的节点。默认值：无现象：若OSD进程所在CPU和与网卡中断相同，可能会出现个别CPU和压力过大的情况修改建议：分离CPU负载压力，避免OSD进程与网卡中断或其他高CPU消耗的进程运行在同一NUMA节点上说明：Ceph OSD守护进程应当与网卡软中断在不同的NUMA节点上处理，否则在网络压力大的时候容易出现CPU瓶颈。Ceph默认会将OSD进程均匀地分不到所有CPU core，可以在ceph.conf中加入osd_numa_node配置选项，避免OSD进程与网卡中断或其他高CPU消耗的进程运行在同一NUMA节点上。网络性能调优将网卡软中断绑定到所属NUMA节点的CPU core上，当网络压力较大时，绑定了软中断的CPU core利用率较高，建议将osd_numa_node设置为与网卡不同的NUMA节点。例如，通过命令cat /sys/class/net/ <网口名> /device/numa_node查询到网卡归属于NUMA节点2，则设置osd_numa_node = 0或者osd_numa_node = 1，尽量避免OSD与网卡软中断使用相同的CPU core。具体优化项如表3所示。

目  录1 软件介绍2 环境配置3 软件安装3.1 BishengJDK安装3.2 Maven安装3.3 Ratis-thirdparty安装3.4 Alluxio编译安装3.5 迁移结果检测4 软件运行4.1 运行alluxio5 其他1 软件介绍Alluxio是一个基于内存的分布式文件系统，它是架构在底层分布式文件系统和上层分布式计算框架之间的一个中间件，主要职责是以文件形式在内存或其它存储设施中提供数据的存取服务。  2 环境配置本文档基于TaiShan 200服务器硬件环境展开。服务器TaiShan 200 2280处理器2*KunPeng 920 4826内存16*32G 2666MHz系统盘1 * 1.2T SATA HDD数据盘1 * 960G SSD网络1 * GE(板载)  1 * 10GE(1822)  软件平台软件名称版本号安装方法备注CentOS7.6https://support.huawei.com/enterprise/zh/doc/EDOC1100088654/3e971c8d本文档安装过程选择的环境为“Server with GUI”，并附加了“Development Tools”。BishengJDK8u272详见4.1章节OpenJDK或者毕昇JDK 均可，要求1.8后的版本Maven3.6.1详见4.2章节要求3.3.9或其后的版本Ratis-thirdparty0.5.0详见4.3章节Alluxio v2.4.1依赖于该jar包的0.5.0版本  3 软件安装3.1 BishengJDK安装3.1.1 下载并解压BishengJDK 8u272版本本文档将文件解压到/opt目录，请根据实际需要选择解压目录wget https://mirrors.huaweicloud.com/kunpeng/archive/compiler/bisheng_jdk/bisheng-jdk-8u272-linux-aarch64.tar.gz tar –zxvf bisheng-jdk-8u272-linux-aarch64.tar.gz -C /opt3.1.2 配置环境变量vi /etc/profile # 将以下环境变量信息粘贴到profile文件最末尾。 # 注意：如果步骤1修改了目录，请修改JAVA_HOME为实际路径 export JAVA_HOME=/opt/bisheng-jdk1.8.0_272 export JRE_HOME=$JAVA_HOME/jre export CLASSPATH=$JAVA_HOME/lib;$JRE_HOME/lib:$CLASSPATH export PATH=$JAVA_HOME/bin:$PATH3.1.3 生效环境变量source /etc/profile3.1.4 检查版本信息java -version3.2 Maven安装3.2.1 下载并解压Maven 3.6.1版本本文档将文件解压到/opt目录，请根据实际需要选择解压目录wget https://archive.apache.org/dist/maven/maven-3/3.6.1/binaries/apache-maven-3.6.1-bin.tar.gz tar –zxvf apache-maven-3.6.1-bin.tar.gz -C /opt3.2.2 配置环境变量vi /etc/profile # 将以下环境变量信息粘贴到profile文件最末尾。 # 注意：如果步骤1修改了目录，请修改MAVEN_HOME为实际路径 export MAVEN_HOME=/opt/apache-maven-3.6.1 export PATH=$MAVEN_HOME/bin:$PATH3.2.3 生效环境变量source /etc/profile3.2.4 检查版本信息mvn -v3.3 Ratis-thirdparty安装3.3.1 下载并解压ratis-thirdparty 0.5.0-rc0版本本文档将文件解压到/opt目录，请根据实际需要选择解压目录wget https://github.com/apache/ratis-thirdparty/archive/0.5.0-rc0.tar.gz tar –zxvf 0.5.0-rc0.tar.gz -C /opt cd ratis-thirdparty-0.5.0-rc03.3.2 添加插件源参考vi pom.xml 将以下仓库信息粘贴到properties标签后。 <pluginRepositories> <pluginRepository> <id>kunpeng</id> <url>http://mirrors.huaweicloud.com/kunpeng/maven</url> <snapshots> <enabled>true</enabled> </snapshots> </pluginRepository> <pluginRepository> <id>huaweicloud-plugin</id> <url>http://mirrors.huaweicloud.com/repository/maven</url> <snapshots> <enabled>true</enabled> </snapshots> </pluginRepository> </pluginRepositories>3.3.3 修改misc/pom.xml中x86链接库为aarch64链接库vi misc/pom.xml #删除x86_64相关的dll和jnilib信息，将so改为aarch64 <exclude>META-INF/native/libnetty_tcnative_linux_aarch64.so</exclude> <fileSet> <sourceFile>${project.build.directory}/classes/META-INF/native/libnetty_tcnative_linux_aarch64.so</sourceFile> <destinationFile>${project.build.directory}/classes/META-INF/native/lib${ratis.thirdparty.shaded.native.prefix}netty_tcnative_linux_aarch64.so</destinationFile> </fileSet>3.4.4 编译安装。cd misc mvn clean install -DskipTests如果没有修改maven依赖包的保存路径，默认会在~/.m2/repository/下生成相关的jar，如下3.4.5 检验jar包迁移结果安装鲲鹏代码迁移工具Porting advisor（指导书见：https://support.huaweicloud.com/ug-pa-kunpengdevps/kunpengpt_06_0004.html ），并对生成的ratis-thirdparty-misc-0.5.0.jar进行扫描，结果如下3.4 Alluxio编译安装3.4.1 下载依赖库 yum install –y git3.4.2 下载alluxio v2.4.1源码不建议采用github的releases包，编译过程缺少git版本信息，需要修改部分文件才能完成编译。如无外网环境，可在其他机器下载源码再转发到服务器上。git clone --branch v2.4.1 https://github.com/Alluxio/alluxio.git cd alluxio3.4.3 修改依赖仓库源和插件源vi pom.xml #在repositories标签内头部添加Kunpeng镜像仓 #在repositories标签后添加插件源 <repositories> <repository> <id>kunpeng</id> <url>https://mirrors.huaweicloud.com/kunpeng/maven/</url> <releases> <enabled>true</enabled> </releases> </repository> … <pluginRepositories> <pluginRepository> <id>kunpeng</id> <url>http://mirrors.huaweicloud.com/kunpeng/maven</url> <snapshots> <enabled>true</enabled> </snapshots> </pluginRepository> <pluginRepository> <id>huaweicloud-plugin</id> <url>http://mirrors.huaweicloud.com/repository/maven</url> <snapshots> <enabled>true</enabled> </snapshots> </pluginRepository> </pluginRepositories>3.4.4 修改x86链接库信息vi shared/client/pom.xml将x86_64的链接库信息修改为aarch643.4.5 编译alluxio如果添加其他插件的支持，请参考官方文案（见第六章）mvn clean install -DskipTests3.5 迁移结果检测3.5.1 安装鲲鹏代码迁移工具Porting advisor指导书见：https://support.huaweicloud.com/ug-pa-kunpengdevps/kunpengpt_06_0004.html 3.5.2 将alluxio文件夹复制到指定目录下登录Porting advisor并创建用户后，将文件夹复制到扫描的目录cp –r alluxio /opt/portadv/portadmin/package3.5.3 使用“分析软件包”功能扫描alluxio由于整个alluxio文件夹较大，无法一次性完成扫描，所以分多次扫描子目录，以下图片仅展示部分结果 4 软件运行4.1 运行alluxio4.1.1 创建默认存储目录默认配置下文件夹为underFSStorage，必须手动创建，如需修改请先复制conf/alluxio-env.sh.template为conf/alluxio-env.sh并修改cd alluxio mkdir ./underFSStorage4.1.2 执行环境验证 ./bin/alluxio validateEnv local4.1.3 执行格式化 ./bin/alluxio format4.1.4 启动服务./bin/alluxio-start.sh local SudoMount4.1.5 运行自带的简单测试./bin/alluxio runTests4.1.6 登录后台查看具体详情 http://localhost:19999 5 其他参考文档：https://docs.alluxio.io/os/user/stable/en/contributor/Building-Alluxio-From-Source.html建议查看英文文档，中文文档部分章节久未更新，与实际使用不符            

存储集群配置7200转硬盘，更换其中一块为5900转的硬盘模拟慢盘观察ceph性能相关统计插入一块 5900rpm 硬盘模拟慢盘：vdbench 对存储集群打上背景压力：iostat，可见性能差的盘“sdn”占用率较高,优先达到瓶颈，会影响整体性能同时观察osd延时，sdn（osd.0）明显高于其他osd，左边osd0，右边osd1ceph daemonperf osd.0 ceph daemonperf osd.1抓取 ceph osd perf记录，200次，观察ceph osd tree 延时的平均值，if [ $# != 1 ]thenecho "please input the num, example: ./$0 200"exit 1fia=$1file="log_perf.log"mv $file ${file}_`date +%Y%m%d%H%M%S`.logfor((i=1;i<=$a;i++))doceph osd perf >> $filesleep 1echo "times= $i " >> $file#t1=`date +%T`t1=`date`echo "time: $t1" >> $fileecho "*****************************************************************************************"for j in {0..35}doif [ $j -lt 10 ]thencat $file |grep -E '^ '${j}'' |awk -F " " '{sum += $3} END { print "osd = " '$j' "," "round = " NR "," "sum = " sum "," "lat_average(ms) = " sum/NR }'elsecat $file |grep -E '^ '${j}'' |awk -F " " '{sum += $3} END { print "osd = " '$j' "," "round = " NR "," "sum = " sum "," "lat_average(ms) = " sum/NR }'fidonedone可观察到osd.0延时明显大于其他osd：slow ops模拟：osd_recovery_max_active = 100osd_recovery_max_single_start = 30osd_max_backfills = 30观察集群状态：

方法：hdparm模拟坏扇区:模拟方法（会破坏数据，也可能对硬盘造成不可逆破坏，慎用）：读：hdparm --read-sector 1000 /dev/sdb注入：hdparm --make-bad-sector 3000 --yes-i-know-what-i-am-doing /dev/sdb修复： hdparm --write-sector 1000 --yes-i-know-what-i-am-doing /dev/sdb （修复的同时，扇区数据也会被写入全0）模拟硬盘扇区故障，查看ceph的文件一致性：创建测试资源池，为方便找到目标文件，只创建1个pg的poolceph osd pool create hdparm 1ceph osd pool application enable hdparm rbd在client上挂载：PG：【22 34 6】用upmap方式把主pg挪到 目标盘上：---------------------------------------------------------------------------先对备份副本pg做测试：ceph osd pg-upmap-items 131.0 6 0当前文件：拷贝文件到/foo0目录：文件增加：/var/lib/ceph/osd/ceph-0/current/131.0_head查询其中一个文件所在扇区：byte_offset begin_LBA end_LBA sectors0 3910896008 3910904199 8192利用hdparm制造扇区故障：hdparm --make-bad-sector 3910903000 --yes-i-know-what-i-am-doing /dev/sdm利用hdparm制造扇区故障：先读测试一下：hdparm --read-sector 3910903000 /dev/sdmhdparm --make-bad-sector 3910903000 --yes-i-know-what-i-am-doing /dev/sdm注错成功，无法读出：在客户端访问数据，拷贝成功（数据从主pg获取，注错的是副本pg），md5校验没有问题：执行 deep-scrub 看是否能检查出问题：执行：ceph pg deep-scrub 131.0等待检查完毕：修复：ceph pg repair 131.0开始修复：修复完毕读之前注错的扇区数据恢复可读：对主pg注错：查看主pg在osd.12上：hdparm --fibmap rbd\\udata.8c9283fc24fbff.0000000000000017__head_5F30262E__83filesystem blocksize 4096, begins at LBA 0; assuming 512 byte sectors.byte_offset begin_LBA end_LBA sectors0 6446684624 6446692815 8192注错：注入：hdparm --make-bad-sector 6446690000 --yes-i-know-what-i-am-doing /dev/sdm读：hdparm --read-sector 6446690000 /dev/sdm在node2 和client端，都清一下缓存：echo 3 > /proc/sys/vm/drop_cache拷贝时卡住一段时间，然后完成拷贝。拷贝卡住，一直到osd.12被置为down，拷贝才完成：文件拷贝完成，md5sum未出错：数据损坏的pg被自动修复，集群状态自动恢复OKceph-osd.12.log中可见日志提示从其他副本拷贝数据回来

【功能模块】【操作步骤&问题现象】1、服务器是TaiShan 200 (Model 2280) Kunpeng 920 （48核）。请问mindspore能否支持利用CPU进行数据并行或模型并行操作？【截图信息】

大家好！我是酷哥，数据库相关资讯，带您速览，欢迎大家阅读。 **本期整理如下：** ----------------------------------------------- **本期精选** ------------------------------------------------ - 华为、腾讯、阿里、字节等纷纷布局东数西算 - 解码高瓴的数据库布局：开源、分布式、图数据库、实时数据 - GreenPlum完全兼容欧拉开源操作系统 - 开源数据库MariaDB通过SPAC再**，开启新征程 - 通用数据库管理工具DBeaver 21.3.5 发布 - SQLite 3.38正式发布：改进JSON支持 增强CLI体验 - PostgreSQL 开始支持 Zstd - 最快的SQL计算引擎MatrixOne 0.2.0 发布 - 云迁移将持续深入，今年企业IT支出将超过1.3万亿美元 - 观远数据完成老虎**基金领投的2.8亿元C轮融资 - 时序数据库 Timescale 完成C轮1.1亿融资，数据库领域添独角兽 - 中国自主的数据库评测，是如何开展的？ - 中国信通院——开源分布式关系型数据库专刊正式启动 ------------------------------------------------ **资讯全文** ------------------------------------------------ - 华为、腾讯、阿里、字节等纷纷布局东数西算 **摘要：** 财联社《TMT时报》上海报道 作为数字经济的核心基础设施，数据中心正迎来新一轮发展契机。华为、腾讯、阿里、字节等纷纷布局东数西算。 “东数西算”工程于近日正式全面启动，计划在京津冀、长三角、粤港澳大湾区、成渝、贵州、内蒙古、甘肃、宁夏8地布局建设全国一体化算力网络国家枢纽节点，并规划10个国家数据中心集群。国内数据中心产业链上下游企业均有望受益。 **文章详情：** https://tieba.baidu.com/p/7735484697 - 解码高瓴的数据库布局：开源、分布式、图数据库、实时数据 **摘要：** 过去一年是国产数据库诞生以来投融资最为火热的一年。作为基础软件的“三驾马车”之一，这个过往的冷门赛道，在2021年内，出现了几个指标性拐点数字：明星公司PingCap估值高达180亿，超过20家数据库企业获得新融资，而以高瓴、红杉、腾讯为代表的头部基金们出手数据库的次数均超过了3家。 **文章详情：** https://tieba.baidu.com/p/7738189880 - GreenPlum完全兼容欧拉开源操作系统 **摘要：** 近日，Greenplum 社区和欧拉开源社区深化合作，在欧拉开源操作系统（openEuler，简称“欧拉”）编译测试了高级分析数据平台 Greenplum，用实践证明了 Greenplum 与支持多样性计算的欧拉开源操作系统完全兼容，是 Greenplum 深入合作的典型模板，大大丰富了产品应用生态。 基于本次合作内容，Greenplum开源社区与欧拉开源社区联合发布白皮书《开源Greenplum新篇章：兼容欧拉开源操作系统的数据平台，支持国产生态的高级分析数据平台》。 **文章详情：** https://tieba.baidu.com/p/7735489906 - 开源数据库MariaDB通过SPAC再**，开启新征程 **摘要：** 元老级数据库企业MariaDB，借助SPAC，携手Angel Pond实现资本新**。 在数据库创投热中，最新的一个爆炸性消息发生在2022年2月初，开源关系型数据库MariaDB宣布完成1.04亿美元的D轮融资。然而不仅如此， MariaDB同时还宣布打算通过与特殊目的收购企业 Angel Pond Holdings 合并，于2022年下半年在纽约证券交易所公开上市。届时该公司将更名"MariaDB plc"，并由现任首席执行官 Michael Howard 继续领导。预计交易完成后，新公司或拥有6.72亿美元估值，获得包括来自Angel Pond以信托方式持有的2.65亿美金以及1800万美元的PIPE投资。 **文章详情：** https://tieba.baidu.com/p/7739194200 - 通用数据库管理工具DBeaver 21.3.5 发布 **摘要：** DBeaver 正式21.3.5 发布。DBeaver 是一个免费开源的通用数据库工具和 SQL 客户端，支持 MySQL, PostgreSQL, Oracle, DB2, MSSQL, Sybase, Mimer, HSQLDB, Derby, 以及其他兼容 JDBC 的数据库。DBeaver 提供一个图形界面用来查看数据库结构、执行SQL查询和脚本，浏览和导出数据，处理BLOB/CLOB 数据，修改数据库结构等等。适用于开发人员和数据库管理员。 **文章详情：** https://tieba.baidu.com/p/7735426577 - SQLite 3.38正式发布：改进JSON支持 增强CLI体验 **摘要：** 作为 2022 年的首个新版，SQLite 3.38 也是 SQLite 的一次盛大更新。SQLite 是一个小型、快速、自包含、高可靠性、全功能的嵌入式 SQL 数据库引擎。早在 2015 年发布的 SQLite 3.9 版本中，开发者就已经为它添加了对 JSON1 模块的支持。现在，随着 2022 年首个重大更新的发布，该模块已在 SQLite 3.38 中被默认包含、而无需启用编译时选项。 **文章详情：** https://tieba.baidu.com/p/7738195534 - PostgreSQL 开始支持 Zstd **摘要：** PostgreSQL 现已通过其 TOAST 存储技术提供压缩支持，并且在过去的一年里构建了 LZ4 压缩支持——用于压缩 WAL、备份压缩以及其他用途，现在 PostgreSQL 开发者正准备通过 Zstd 支持进一步扩展其压缩能力。 Zstd (Zstandard) 是由 Facebook 开源的快速无损压缩算法，主要应用于 zlib 级别的实时压缩场景，并且具有更好的压缩比。Zstd 还可以以压缩速度为代价提供更强的压缩比，速度与压缩权衡可通过小增量进行配置。 **文章详情：** https://tieba.baidu.com/p/7735437424 - 最快的SQL计算引擎MatrixOne 0.2.0 发布 **摘要：** 在数月的打磨和努力开发之下, MatrixOne 0.2版本正式发布啦！ 项目文档网站 https://docs.matrixorigin.io/0.2.0/ 相比于0.1版本，0.2版本在以下几方面有着明显改进：性能大幅提升、完整的分布式能力、新Feature、文档更新、 Bug Fixes等。 **文章详情：** https://tieba.baidu.com/p/7739181210 - 云迁移将持续深入，今年企业IT支出将超过1.3万亿美元 **摘要：** 2月21日消息，Gartner预测预测，2025年有效细分市场中的企业在公有云计算领域的IT支出将超过传统IT服务支出。 Gartner云迁移研究包括可以迁移到云的企业IT市场，即应用软件、基础设施软件、业务流程服务和系统基础设施市场。2025年在这四个市场中将有51%的IT支出从传统解决方案转向公有云(2022年为41%)。 Gartner预测，2022年企业IT支出将因云迁移而超过1.3万亿美元，2025年将增长至近1.8万亿美元。分布式云等新技术的出现将扩大云在IT市场引发的持续变革。 **文章详情：** https://tieba.baidu.com/p/7736599583 - 观远数据完成老虎**基金领投的2.8亿元C轮融资 **摘要：** 2月22日，BI服务商观远数据宣布完成新一轮2.8亿元C轮融资。本轮融资由全球知名的老虎**基金(Tiger Global)领投，红杉中国、线性资本、襄禾资本、独秀资本(Unicorn Capital Parnters)等老股东全线跟投。据观远数据创始人&CEO苏春园介绍，此轮融资将主要用于三大方面，智能分析产品矩阵的深化、客户成功体系的升级、重点行业与用户生态的建设。 数字化时代正在加速到来，商业智能将广泛普及，以数据驱动决策将成为企业的常态。IDC预测，2025年，中国商业智能软件市场规模将达到13.3亿美元，未来5年整体市场年复合增长率(CAGR)达到17.9%。 **文章详情：** https://tieba.baidu.com/p/7736623942 - 时序数据库 Timescale 完成C轮1.1亿融资，数据库领域添独角兽 **摘要：** 2022 年 2 月 22 日，Timescale 宣布其在近日完成了 C 轮融资，在 2021 年、2019 年和 2018 年，Timescale 分别完成了 4000 万美元、1500 万美元和 1600 万美元的融资，总融资金额达到 1.8 亿美元。本轮融资由 Tiger Global 领投，现有投资者 Benchmark、New Enterprise Associates、Redpoint Ventures、Icon Ventures 和 Two Sigma Ventures 均参与跟投。目前，Timescale 估值超过 10 亿美元，成为数据库领域的又一独角兽企业。 **文章详情：** https://tieba.baidu.com/p/7738209746 - 中国自主的数据库评测，是如何开展的 **摘要：** 此前，较受认可的评测是由 TPC（ Transaction Processing Performance Council，事务处理性能委员会）推出的 TPC-C 评测标准，而 TPC-C 也一度成为每个主流数据库都会尝试一下的评测。但 TPC-C 也有自身的问题，首先，它面向的是 OLTP 数据库，并不能满足所有场景的数据库测试。实际上，TPC 只给出了标准规范，特别场景需要厂商自行处理。另外，TPC 的审核人员人数很少，且全部在**，沟通不便。从开销的角度讲，TPC-C 也较为昂贵，比如 Oracle 从 2010 年开始，就基本退出了 TPC-C 评测。 种种因素，使数据库评测处于一个事实上的空白领域。这也促使国内许多机构开始尝试进行数据库标准评测，信通院作为我国工业和信息化部直属事业单位，有推动我国 ICT 领域健康、快速发展的直接责任，因此从 2015 年开始推出各类数据库评测，在整个行业都产生了较大的影响力。 **文章详情：** https://tieba.baidu.com/p/7736427945 - 中国信通院——开源分布式关系型数据库专刊正式启动 **摘要：** 近年来，开源生态发展势头迅猛，开源在推动技术创新、促进产业协作、加快各行业数字化进程方面发挥的作用日益凸显。过去一年，开源生态进一步发展成熟，并呈现全新态势。开源生态从个人参与到企业参与，从开源技术交流到开源生态协同，逐步形成产业供应关系。自上而**系化构建方式与自下而上竞争式模式相结合，不断推动开源生态发展。 开源已成为企业的主流趋势，也将成为企业的战略方向和商业模式。开源改变了信息产业的格局和商业模式，推动全球信息技术发生了全局性、持续性的重大变革，促进了全球范围内的技术创新成果落地。基于此背景，中国信息通信研究院前期已成功编写并发布了《开源发展态势洞察报告——消息中间件专刊》。 中国信通院第二期《开源发展态势洞察报告》—开源分布式关系型数据库专刊现公开征集参与单位，欢迎社会各界广泛参与！ **文章详情：** https://tieba.baidu.com/p/7739152732 [上一期：【技术之声】第九期（20220221）一周精选](https://bbs.huaweicloud.com/forum/thread-180163-1-1.html) *声明：文章源于第三方公开的信息，如内容中涉嫌侵权或存在信息不实时，请及时联系删除。* |整理者：酷哥