CN117675552A - 一种集群的创建方法和相关装置 - Google Patents

Abstract

本申请实施例公开了一种集群的创建方法和相关装置，可应用于云技术、人工智能、智慧交通、辅助驾驶、大数据处理等各种场景。获取组件配置参数，组件配置参数用于表征待创建集群创建所需的多个组件。根据多个组件间的耦合关系，将至少两个具有耦合关系的组件分配至不同的主机中。其中，耦合关系能够体现两个组件间是否相互影响，将相互影响的两个组件分配至不同的主机中，实现组件之间的相互隔离，能够降低具有耦合关系的组件恶意争抢同一个主机的硬件资源，提高集群性能。从而依据耦合关系得到多个组件和多个主机间的安装关系，根据该安装关系，将多个组件分别安装至多个主机中，进而得到待创建集群。

Description

一种集群的创建方法和相关装置

技术领域

本申请涉及通信技术领域，特别是涉及一种集群的创建方法和相关装置。

背景技术

集群是一组相互独立的、通过高速网络互联的计算机。目标是解决对于任何单一的大型计算机来说仍然大得难以解决的问题，并同时保持解决多个较小的问题的灵活性。

目前，部署搭建集群需要技术人员编写大量的组件的代码，并手动分发到每一台主机上，不仅工作量大，而且创建的集群在运行过程中会出现多个组件恶意争抢底层硬件资源，导致集群性能下降等问题。

发明内容

为了解决上述技术问题，本申请提供了一种集群的创建方法和相关装置，用于降低工作量，提高集群性能。

本申请实施例公开了如下技术方案：

一方面，本申请实施例提供一种集群的创建方法，所述方法包括：

获取组件配置参数，所述组件配置参数用于表征待创建集群所需的多个组件；

根据所述多个组件间的耦合关系，将至少两个具有所述耦合关系的组件分配至不同的主机中，得到所述多个组件和多个所述主机间的安装关系，所述主机为用于创建所述待创建集群的节点；

根据所述安装关系，将所述多个组件分别安装至多个所述主机中，以得到所述待创建集群。

另一方面，本申请实施例提供一种集群的创建装置，所述装置包括：获取单元、分配单元和安装单元；

所述获取单元，用于获取组件配置参数，所述组件配置参数用于表征待创建集群所需的多个组件；

所述分配单元，用于根据所述多个组件间的耦合关系，将至少两个具有所述耦合关系的组件分配至不同的主机中，得到所述多个组件和多个所述主机间的安装关系，所述主机为用于创建所述待创建集群的节点；

所述安装单元，用于根据所述安装关系，将所述多个组件分别安装至多个所述主机中，以得到所述待创建集群。

另一方面，本申请实施例提供一种计算机设备，所述计算机设备包括处理器以及存储器：

所述存储器用于存储计算机程序，并将所述计算机程序传输给所述处理器；

所述处理器用于根据所述计算机程序中的指令执行上述方面所述的方法。

另一方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质用于存储计算机程序，所述计算机程序用于执行上述方面所述的方法。

另一方面，本申请实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述方面所述的方法。

由上述技术方案可以看出，获取组件配置参数，组件配置参数用于表征待创建集群创建所需的多个组件。根据多个组件间的耦合关系，将至少两个具有耦合关系的组件分配至不同的主机中。其中，耦合关系能够体现两个组件间是否相互影响，将相互影响的两个组件分配至不同的主机中，实现组件之间的相互隔离，能够降低具有耦合关系的组件恶意争抢同一个主机的硬件资源，提高集群性能。从而依据耦合关系得到多个组件和多个主机间的安装关系，根据该安装关系，将多个组件分别安装至多个主机中，进而得到待创建集群。由此，仅需组件配置参数，依据耦合关系将组件配置参数对应的多个组件分别安装至多个主机中，不仅实现了集群的自动创建，还实现组件间的相互隔离，降低恶意争抢底层硬件资源的概率，提高了集群的性能。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的集群的创建方法的应用场景示意图；

图2为本申请实施例提供的集群的创建方法的流程示意图；

图3为本申请实施例提供的一种多个组件间的耦合关系的示意图；

图4为本申请实施例提供的一种创建待创建集群的流程图；

图5为本申请实施例提供的一种集群创建的架构图；

图6为本申请实施例提供的一种存算分离的架构图；

图7a-图7h，为本申请实施例提供的一种集群的创建过程的示意图；

图8为本申请实施例提供的一种待创建集群搭建的时序图；

图9为本申请实施例提供的一种集群的创建装置的结构示意图；

图10为本申请实施例提供的服务器的结构示意图；

图11为本申请实施例提供的终端设备的结构示意图。

具体实施方式

下面结合附图，对本申请的实施例进行描述。

相关技术中，通过人工部署集群会出现以下问题：第一，部署搭建集群需要编写大量的组件对应的代码，工作量大。第二，将编写好的代码手动分发到每一台主机上，容易出错，效率低下。第三，还可能会出现组件分配失衡，使得创建好的集群在运行过程中出现多个组件恶意争抢底层硬件资源，导致集群性能下降。

基于此，本申请实施例提供一种集群的创建方法，通过组件配置参数，依据耦合关系将多个组件分别安装至多个主机中，实现了集群的自动创建，不仅降低了工作量，而且提高了分发效率。而且，还实现组件间的相互隔离，降低恶意争抢底层硬件资源的概率，提高了集群的性能。

本申请实施例提供的集群的创建方法可以应用于具有集群创建能力的设备，如终端设备、服务器。其中，终端包括但不限于手机、电脑、智能语音交互设备、智能家电、车载终端、飞行器等。服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云计算服务的云服务器。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。本申请实施例可应用于各种场景，包括但不限于云技术、人工智能、智慧交通、辅助驾驶等。

本申请实施例提供的集群的创建方法是基于云计算技术实现的，云技术(Cloudtechnology)是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。

云技术(Cloud technology)基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑。技术网络系统的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，只能通过云计算来实现。

通过本申请实施例提供的集群的创建方法搭建集群，该集群能够实现大数据(Bigdata)、私有云(Private Cloud)和公有云(Public Cloud)等功能。下面分别对大数据、私有云和公有云进行说明。

大数据是指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。随着云时代的来临，大数据也吸引了越来越多的关注，大数据需要特殊的技术，以有效地处理大量的容忍经过时间内的数据。适用于大数据的技术，包括大规模并行处理数据库、数据挖掘、分布式文件系统、分布式数据库、云计算平台、互联网和可扩展的存储系统。

私有云是将云基础设施与软硬件资源创建在防火墙内，以供机构或企业内各部门共享数据中心内的资源。创建私有云，除了硬件资源外，一般还有云设备(IaaS，Infrastructure as a Service，基础设施即服务)软件。私有云计算同样包含云硬件、云平台、云服务三个层次。不同的是，云硬件是用户自己的个人电脑或服务器，而非云计算厂商的数据中心。云计算厂商构建数据中心的目的是为千百万用户提供公共云服务，因此需要拥有几十上百万台服务器。私有云计算，对个人来说只服务于亲朋好友，对企业来说只服务于本企业员工以及本企业的客户和供应商，因此个人或企业自己的个人电脑或服务器已经足够用来提供云服务。

公有云通常指第三方提供商为用户提供的能够使用的云，公有云一般可通过Internet使用，可能是免费或成本低廉的，公有云的核心属性是共享资源服务。这种云有许多实例，可在当今整个开放的公有网络中提供服务。

为了便于理解本申请实施例提供的集群的创建方法，下面以该集群的创建方法的执行主体为服务器为例，对该集群的创建方法的应用场景进行示例性介绍。

参见图1，该图为本申请实施例提供的集群的创建方法的应用场景示意图。如图1所示，该应用场景中包括终端设备110、服务器120、主机130和主机140，终端设备110与服务器120之间可以通过网络通信、服务器120与多个主机之间也可以通过网络通信。

在实际应用中，用户可以通过终端设备110输入组件配置参数，终端设备110将组件配置参数发送给服务器120。其中，组件配置参数用于表征待创建集群创建所需的多个组件，例如，用户想要创建的集群需要组件A、组件B和组件C。

服务器120根据组件配置参数和多个组件间的耦合关系，建立多个组件和多个主机130间的安装关系。其中，根据多个组件间的耦合关系，将至少两个具有耦合关系的组件分配至不同的主机中。耦合关系能够体现两个组件间是否相互影响，或者说是否具有依赖关系，将具有耦合关系的两个组件分配至不同的主机中，实现组件之间的相互隔离，能够降低具有耦合关系的组件恶意争抢同一个主机的硬件资源，从而提高集群性能。例如，组件A和组件B具有耦合关系，组件A和组件C具有耦合关系，则将组件A分配至主机130中安装，将组件B和组件C分配至主机140中安装。

服务器120依据耦合关系得到多个组件和多个主机间的安装关系，根据该安装关系，将多个组件分别安装至多个主机中，进而得到待创建集群。由此，用户仅需关注组件配置参数，服务器会自动依据组件间的耦合关系将组件配置参数对应的多个组件分别安装至多个主机中，不仅实现了集群的自动创建，还实现组件间的相互隔离，降低恶意争抢底层硬件资源的概率，提高了集群的性能。

本申请实施例所提供的集群的创建方法可以由服务器执行。但是，在本申请的其它实施例中，终端设备也可以与服务器具有相似的功能，从而执行本申请实施例所提供的集群的创建方法，或者由终端设备和服务器共同执行本申请实施例所提供的集群的创建方法，本实施例对此不做限定。

下面通过方法实施例对本申请提供的集群的创建方法进行详细介绍。

参见图2，该图为本申请实施例提供的集群的创建方法的流程示意图。为了便于描述，下述实施例仍以该集群的创建方法的执行主体为服务器为例进行介绍。如图2所示，该集群的创建方法包括以下步骤：

S201：获取组件配置参数。

其中，组件配置参数用于表征待创建集群所需的多个组件。待创建集群是用户想要创建的集群，集群是为解决大规模的计算问题提供一个模型。目标是解决对于任何单一的大型计算机来说仍然大得难以解决的问题，并同时保持解决多个较小的问题的灵活性。集群包括多个组件，组件提供集群内各项服务功能的健康状态检测，可以查看当前集群的健康状态和运行时间，能够帮助用户监测集群的状况和及时定位问题。

下面以三种方式为例对服务器获取组件配置参数进行说明。方式一：用户可以通过终端设备直接输入组件配置参数，此时终端设备中安装有与服务器进行通讯的客户端。方式二：由服务器根据当前硬件设施自动生成默认的组件配置参数，提供给用户进行修改、确认等。方式三：服务器或者终端设备展示包括所有组件的组件列表，以便用户根据组件列表选择所需的组件，从而根据用户选择的组件生成组件配置参数。

作为一种可能的实现方式，服务器可以部署在云平台，用户可以通过终端设备接入云平台的服务器，从而完成集群的创建。作为一种可能的实现方式，终端设备可以安装有客户端，客户端可以展示窗口界面，以便通过窗口界面展示组件供用户选择等。该应用程序可以是基于云平台开发的。

S202：根据多个组件间的耦合关系，将至少两个具有耦合关系的组件分配至不同的主机中，得到多个组件和多个主机间的安装关系。

待创建集群在创建的过程中，需要多个组件，每个组件至少提供一种服务，从而通过多个组件配合实现集群的相应功能。经过研究发现，组件间具有耦合关系，或者说组件和组件之间可能会相互影响、相互依赖。耦合关系用于表征组件与组件之间信息或参数依赖的程度。当一个组件发生变化后对另一个组件的影响很小，则称它们是松散耦合的；反之，如果变化的影响很大时，则称它们是紧密耦合的。耦合的强弱取决于组件间的复杂性、引用组件的位置和数据的传送方式等。

若将具有耦合关系的两个组件安装至同一个主机中，还会出现以下问题。第一，一个主机的资源有限，可能会出现具有耦合关系的组件均需要运行，从而出现多个组件恶意争抢底层硬件资源，导致集群性能下降。第二，若安装两个具有耦合关系的组件的主机，以及两个组件副本所在的主机同时宕机，则会导致两个组件均不可用，无法提供对应的服务，会降低该待创建集群的高可用性。

其中，高可用是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统(如本申请实施例中待创建集群中的系统)不能提供服务的时间，即系统无中断地执行其功能的能力，代表系统的可用性程度。假设系统一直能够提供服务，则系统的可用性是100％；如果系统每运行100个时间单位，会有1个时间单位无法提供服务，则系统的可用性是99％。系统可用性越高，则系统高可用性能越好。

基于此，为了避免上述问题，本申请实施例将至少两个具有耦合关系的组件分配至不同的主机中，即具有耦合关系的两个组件，一个组件被分配至一个主机中，另一个组件被分配至另一个主机中，从而得到多个组件和多个主机的安装关系，以便后续基于该安装关系，使得待创建集群在运行过程中，能够降低具有耦合关系的组件恶意争抢同一个主机的硬件资源，提高集群性能。而且，若具有耦合关系的两个组件分别安装至两个主机中，则其对应副本也会分别安装至另外两个主机中，此时需要四个主机同时宕机才会导致两个组件对应的服务不可用，相比于前述两个主机同时宕机就会导致服务不可用，提高了待创建集群的高可用性。其中，主机为用于待创建集群的节点，用于连接到网络的计算机或其他设备，例如主机可以为服务器。

作为一种可能的实现方式，可以通过重新梳理组件间的耦合关系，预先将其存储在服务器中，以便后续直接调用。参见图3，该图为本申请实施例提供的一种多个组件间的耦合关系的示意图。在图3中，通过箭头连接的两个组件具有耦合关系，例如，Guldan和Portal具有耦合关系。下面分别对图3中涉及的各个组件进行说明。

Portal：用于实现大数据平台功能的组件，其提供统一、易用的可视化平台管理页面，可以包括单点登录功能、项目快捷管理功能、资源/任务审批功能、消息告警功能以及组件自身管理页面的快捷访问入口等功能。

Guldan：用于实现统一调度的组件，其具有毫秒级任务下发，高可靠性，同时支持插件式扩展任务类型等。

Uther：用于实现数据管理功能的组件，提供Hive(基于Hadoop的数据仓库工具)、Hbase(基于Hdfs的分布式列式数据库)、Kafka(分布式消息中间件)、MPP数仓(基于MPP引擎的相关功能)等系统源的库表管理和库管权限控制功能等。

Mysql：一个关系型数据库管理系统。

Zookeeper：一个分布式的，开放源码的分布式应用程序协调服务。

Spark：集交互SQL查询、批处理、流式计算、图计算、机器学习为一身的新一代大数据计算框架。

Hdfs：Hadoop分布式文件存储系统。

Yarn：提供统一的资源管理和调度能力。

idex：一种交互式数据探索工具。

ranger：一种大数据权限管控工具。

需要说明的是，两个组件之间的通信，均需要在Zookeeper中获取被访问的组件的通信地址，在图3中仅以虚线箭头示例性的进行表示，如Guldan可以在Zookeeper中获取Uther的通信地址，从而基于该通信地址访问Uther。

S203：根据安装关系，将多个组件分别安装至多个主机中，以得到待创建集群。

由于前述将至少两个具有耦合关系的组件分配至不同的主机中，故得到的安装关系中降低了具有耦合关系的组件被分配至同一主机中的概率，若提高该概率，还可以实现将多个具有耦合关系的组件进行隔离，从而在依据该安装关系将多个组件安装至多个主机中，得到待创建集群后，在运行待创建集群的过程中，由于具有耦合关系的组件被安装至不同的主机中，降低了多个具有耦合关系的组件恶意争抢底层硬件资源的概率，从而提高了集群性能和高可用性。

作为一种可能的实现方式，可以通过程序将组件安装至主机中。上述程序可以包括操作系统、用于实现相应功能的应用程序。其中，操作系统为待创建集群中主机提供基础的运行环境，应用程序可以为实现组件对应功能的应用程序。例如，若待创建集群为消息队列集群，则应用程序可以为rabbitmq应用程序或kafka应用程序。

作为一种可能的实现方式，上述程序还可以包括：集群软件，集群软件检测待创建集群中主机上安装的应用程序，并与应用程序协作为用户提供所需的服务，如消息队列服务。

作为一种可能的实现方式，待创建集群被创建成功后，在运行过程中，待创建集群中各主机上安装的集群软件会负责检测其上应用程序的运行状态，而且待创建集群中各主机彼此之间也会进行周期性的心跳检测，若待创建集群中某个主机发生故障，则待创建集群中另一主机可以立即对其进行接管，并代替其向外提供服务。

由上述技术方案可以看出，获取组件配置参数，组件配置参数用于表征待创建集群创建所需的多个组件。根据多个组件间的耦合关系，将至少两个具有耦合关系的组件分配至不同的主机中。其中，耦合关系能够体现两个组件间是否相互影响，将相互影响的两个组件分配至不同的主机中，实现组件之间的相互隔离，能够降低具有耦合关系的组件恶意争抢同一个主机的硬件资源，提高集群性能。从而依据耦合关系得到多个组件和多个主机间的安装关系，根据该安装关系，将多个组件分别安装至多个主机中，进而得到待创建集群。由此，仅需组件配置参数，依据耦合关系将组件配置参数对应的多个组件分别安装至多个主机中，不仅实现了集群的自动创建，还实现组件间的相互隔离，降低恶意争抢底层硬件资源的概率，提高了集群的性能。

作为一种可能的实现方式，本申请实施例提供一种S202的具体实现方式，即根据多个组件间的耦合关系的强度和数量建立安装关系，具体参见A1-A2：

A1：根据耦合关系的强度或耦合关系的数量，对多个组件进行排序，得到组件顺序关系。

根据耦合关系的强度或耦合关系的数量，对多个组件进行排序存在三种实施方式，分别为仅根据耦合关系的强度对多个组件进行排序、仅根据耦合关系的数量对多个组件进行排序，以及根据耦合关系的强度和耦合关系的数量对多个组件进行排序。

若一个组件的耦合关系较多，或者耦合关系较强则该组件占用的资源较多，例如，实现存储服务的组件，即能够实现存储功能的组件会与很多组件均具有耦合关系，故可以为其优先分配资源较多的主机，从而优先保证实现存储服务的组件的高可用性。

A2：将多个组件按照组件顺序关系从大到小分别作为目标组件，将目标组件分配至目标主机中，将与目标组件具有耦合关系的组件分配至其他主机中，得到多个组件和多个主机间的安装关系。

组件顺序关系用于体现组件在待创建集群中的重要性，例如，耦合关系越强或耦合关系数量阅读的组件在待创建集群中越重要，越需要保证其高可用性，从而提高待创建集群的性能。基于此，根据组件顺序关系，从大到小依次将组件作为目标组件，以便为其优先分配主机。例如，Hdfs作为数据存储功能的组件，很多组件均与其具有耦合关系，在建立组件与主机间的安装关系时，可以优先为Hdfs进行分配。例如，将将Hdfs第一个作为目标组件。在为Hdfs分配好主机后，再建立其他的组件与主机间的安装关系。

其中，目标主机为当前还未与组件具有安装关系的主机中，内存资源最大的主机，即为目标组件优先分配内存资源最大的主机，且与目标组件具有耦合关系的组件未与目标主机建立安装关系。其他主机为多个主机中除目标主机外的主机。

由此，通过耦合关系的强度或耦合关系的数量为多个组件进行排序，并按照组件对待创建集群的重要程度，优先为较为重要的组件分配内存资源较大的主机，从而在不降低性能的前提下，尽可能保证较为重要的组件的高可用性。

由于有些企业并不一定只在大数据量的情况下才有快速的计算以及性能的提高的需求，即使是几千兆(简称GB)、几十个GB规模的数据在高并发的情况下也需要快速的计算和高性能，同时也有企业存在临时性的结构与非结构化数据处理的需求。基于此，本申请实施例提供一种轻量化的大数据平台套件，即针对企业不同的业务需求，基于耦合关系对组件进行裁剪，得到轻量化组件，进而依据安装关系将轻量化组件安装至主机中，得到待创建集群。该待创建集群不仅更符合业务需求，在不影响待创建集群性能的同时，实现了轻量化可插拔，而且能够最大程度节约底层硬件资源。下面通过B1-B5具体进行说明。

B1：获取组件集合和业务需求。

其中，组件集合至少包括待创建集群所需的多个组件，组件包括多个用于实现不同功能的服务组件，服务组件是整个待创建集群在部署过程中，可以独立完成某一服务部署的最小单元。例如，Zookeeper组件中包括两个服务组件，分别是Zookeeper Server和Zookeeper Client，其中，Zookeeper Server用于实现服务器所需的功能，ZookeeperClient用于实现客户端所需的功能。

参见表1，该表为本申请实施例提供的一种组件和服务组件间的关系。

表1

业务需求可以企业对于数据处理的一些需求，不同业务需求所需的功能不同，从而待创建集群所需的组件不同，有可能所需组件相同，但是所需服务组件不同。若企业每增加一个业务需求，就对应增加相应的组件，会导致大数据平台越来越庞大和复杂，对应的硬件资源越来越沉重，底层硬件资源浪费较为严重。

B2：根据耦合关系和业务需求，从目标组件包括的多个服务组件中确定待删除服务组件。

其中，待删除服务组件为不受其他组件的影响，且对实现业务需求无用的服务组件，其他组件为组件集合中除目标组件外的组件，目标组件为组件集合中的一个组件。

例如，基于业务需求能够确定出所需的待创建集群，根据待创建集群所需的功能能够确定出对应的组件，每个组件包括至少一个服务组件，不同服务组件用于实现不同的功能。由此，不同的业务需求最后所需的服务组件不同，进而可以将待创建集群不需要的服务组件，且删除不会影响其他服务组件或组件的服务组件确定为待删除服务组件。

例如，将删除一个服务组件的结果和全量的服务组件的结果进行比较，得到删除的服务组件对其他服务组件的影响，进而依据耦合关系，查看组件间的影响，从而确定待删除服务组件。

B3：从目标组件中裁剪待删除服务组件，得到针对于目标组件的轻量化组件。

将待删除服务组件从目标组件中删除，从而得到针对于目标组件的轻量化组件。下面以三种组件为例进行说明。

(1)轻量化Portal：仅提供个人中心、平台运维、功能模块任务调度、数据资产、idex的入口。

(2)轻量化Guldan：仅提供Hivesql离线批处理计算调度。其中，Hivesql是一种用于Hive分析和处理元存储中结构化数据的查询语言，Hive是一个基于apache hadoop的数据仓库基础设施。

(3)轻量化Uther：仅提供hive的库表管理，没有hbase，任务调度和数据资产需要在513/514版本基础上做裁剪，减少kafka、es、phoenix等组件部署和依赖。其中，hbase是一个开源的、分布式的、版本化的非关系型数据库。Kafka是一种分布式数据存储，es是基于Java开发的开源搜索引擎，phoenix是一个HBase的开源SQL引擎。

由此，将组件集合中每个组件分别作为目标组件，对多个组件分别进行裁剪，得到了多个轻量化组件，进而实现了待创建集群的轻量化部署。

B4：获取多个组件分别对应的轻量化组件。

B5：根据安装关系，将多个组件分别对应的轻量化组件分别安装至多个主机中，以得到待创建集群。

由此，针对企业不同的业务需求，基于耦合关系对组件进行裁剪，得到轻量化组件，进而依据安装关系将轻量化组件安装至主机中，得到待创建集群。该待创建集群不仅更符合业务需求，在不影响待创建集群性能的同时，实现了轻量化可插拔，而且能够最大程度节约底层硬件资源。

进一步的，本申请实施例还提供一种B3的具体实现方式，具体参见C1-C2：

C1：从目标组件中裁剪待删除服务组件，得到初始轻量化组件。

C2：为初始轻量化组件增加镜像服务组件，得到针对于目标组件的轻量化组件。

由此，在将待删除服务组件从目标组件中裁剪后，再增加镜像服务组件，得到针对于目标组件的轻量化组件，例如，将轻量化Guldan的服务部署做成docker镜像，将轻量化Uther的服务部署做成docker镜像。在待创建集群运行的过程中，可以先将与用户无关的功能在镜像中运行，得到运行结果，当与用户有关的功能运行完后，将其与前述得到的运行结果继续运行，得到最终的结果，从而提高了运行速度，降低了主机中运行的组件的数量，即主机中仅运行与用户有关的功能的组件，从而降低资源竞争的概率，提高待创建集群的性能，从而实现了最大化节约底层硬件资源。

相关技术中，至少需要6个节点才能实现待创建集群的创建，但是还是存在资源浪费的问题。通过研究发现，为了避免集群发生冲突，集群中控制节点和工作节点不在一个主机中，故造成了资源浪费。基于此，本申请实施例在相同硬件条件下，通过耦合关系，能够梳理组件以及服务组件间的关系，从而将不具有冲突关系的控制节点和工作节点放置于同一主机中，将6节点降低至4节点，避免了资源浪费。具体地，根据耦合关系，将作为控制节点的服务组件和作为工作节点的服务组件分配至同一主机中，得到多个组件和多个述主机间的安装关系。

其中，一个组件包括多个服务组件，控制节点(master节点)又称为主节点，提供集群的控制面板，也是整个Kubernetes集群的管控中心，负责容器组pod的调度、服务账户以及令牌的管理等等。工作节点(work节点)又称为从节点，work节点主要负责容器的创建，服务的代理以及其他相关应用，即负责承载容器运行，是容器的宿主机。

参见表2，该表提供了服务组件在四个节点上的部署情况，其中Y表示部署，M1表示第一个控制节点，M2表示第二个控制节点，M3表示第三个控制节点，M4表示第四个控制节点。

表2

/>

/>

其中，hdfs组件中，NameNode为控制节点，DataNode为工作节点，二者均被分配至M4中部署。

参见表3，该表为本申请实施例提供的一种集群规模演进方案。

表3

作为一种可能的实现方式，本申请实施例提供一种S202的具体实现方式，下面通过D1-D3进行说明。

D1：获取当前已存在集群的组件安装情况。

由于有的企业在通过本申请实施例提供的集群的创建方法创建集群之前，还创建过其他集群，或者存在待创建集群的历史版本。故可以获取当前已存在集群的组件安装情况。例如，Presto组件是否安装，Hdfs组件是否安装等。

作为一种可能的实现方式，还可以获取当前的操作系统的版本，当前的硬件环境是否符合待创建集群的部署标准等，从而实现初始化。

D2：根据耦合关系和组件安装情况，卸载有冲突组件并得到未安装组件。

其中，有冲突组件为安装在同一主机中具有耦合关系的组件，如当前已存在的集群将具有耦合关系的组件安装至同一主机中，则这两个组件为有冲突组件。为了保证集群的性能，可以将有冲突组件卸载，后续重新建立有冲突组件和主机间的安装关系，实现安装。

基于组件配置参数得到需要安装的多个组件，基于多个组件和组件安装情况，得到多个组件中还未安装的组件，并将其作为未安装组件。

D3：根据耦合关系，将至少两个具有耦合关系的未安装组件分配至不同的主机中，得到未安装组件和多个主机的安装关系。

由此，通过耦合关系重新梳理已存在集群中的组件，确定出有冲突组件并将其卸载，在卸载后将待创建集群所需的多个组件中还未安装的组件与多个主机建立安装关系，以便基于安装关系实现待创建集群的创建，避免从0开始再次创建集群。从而依据耦合关系对已安装的组件进行梳理，并卸载有冲突组件对未安装组件进行安装，在保证待创建集群性能的同时，提高了待创建集群的创建速度。

相关技术中，若两个组件之间具有耦合关系，则一个组件的修改会产生涟漪效应，另一个组件也需要进行修改，导致维护难度大。而且，组件的可复用性较低，其进一步组合可能会需要更多的精力和时间。基于此，本申请实施例在实现组件间隔离的基础上，基于证书信息确定运维策略，从而通过统一的组件管理方式，减低后续的运维成本和难度。下面通过E1-E3进行说明。

E1：获取证书信息。

E2：根据证书信息确定运维策略。

作为一种可能的实现方式，证书信息可以为根据用户购买服务的情况定制化生成的信息，从而基于用户购买服务的情况确定该服务对应的运维策略。又或者，证书信息可以携带企业业务需求的信息，从而基于业务需求为其定制运维策略。

E3：根据运维策略检测待创建集群的运行状况。

需要说明的是，证书信息还可以用于验证用户是否有权限创建待创建集群。

由此，通过对证书信息的统一管理，建立证书信息与运维策略间的映射关系，能够基于证书信息确定运维策略，进而基于运维策略对待创建集群中组件的运行状况进行检测，统一组件的管理方式，降低后续的运维成本和运维难度。

作为一种可能的实现方式，本申请实施例提供了一种通过ambari得到待创建集群的具体实施方式，下面通过F1-F4具体进行说明。

F1：在多个主机中分别安装ambari-sever。

就ambari的作用来说，就是创建、管理、检测Hadoop的集群，但是这里的Hadoop是广义，指的是Hadoop整个生态圈(如Hive、Hbase、Sqoop、Zookeeper等)，也就是说，ambari是为了让Hadoop以及相关的大数据软件更容易使用的一个工具。

其中，ambari-sever将集群的状态通过web UI或RESTAPI的形式呈献给用户，也是通过这两种形式将用户的指令下发到集群，从而完成用户与Hadoop集群的交互。

F2：在多个主机中分别安装ambari-agent。

其中，ambari-agent是由Python语言开发，负责对集群内主机状态的采集以及执行ambari-server发来的指令，将执行结果上报给ambari-server。ambari-agent虽然是离hadoop集群最近的一个模块，但是它不保存集群的任何状态信息，完全听命于ambari-server。

F3：根据安装关系生成多个主机分别对应的蓝图，并通过多个主机中安装ambari-agent将多个主机分别对应的蓝图分别注册到多个主机中安装ambari-sever中。

其中，蓝图包含计算、存储、网络、软件等资源在内的整体应用环境的完整规范定义，用于确定各种资源的属性与依赖关系、工作流和执行策略。可以通过可视化画布进行蓝图设计，将一个或多个组件进行组合，从而创建标准化的服务框架。蓝图注册到ambari-sever后，可用于创建云资源部署服务。

F4：调用ambari接口，根据多个主机分别对应的蓝图将多个组件分别安装至多个主机中，以得到待创建集群。

由此，根据安装信息生成的蓝图，包括创建待创建集群所需的一些信息，从而通过ambari实现组件的安装。

下面结合图4以一个实施例为例进行说明。

参见图4，该图为本申请实施例提供的一种创建待创建集群的流程图。

S401：开始。

S402：判断是否初始化，若是，则执行S403，若否，则执行S405。

判断是否初始化则包括获取当前已存在集群的组件安装情况，从而可以将已存在集群纳管进来。

S403：验证证书信息。

通过获取的证书信息验证用户的身份，是否具有权限创建待创建集群。

S404：在多个主机中分别安装ambari-server。

S405：验证证书信息。

S406：在多个主机中分别安装ambari-server。

S407：判断是否自动部署待创建集群，若是，则执行S408，若否，则执行S411。

S408：验证cluster_info.json文件。

cluster_info.json文件中包括多个组件间的耦合关系，通过md5等安全验证方式对该文件进行验证，以保证集群的安全。作为一种可能的实现方式，cluster_info.json文件中还可以包括待创建集群的版本号、名字等信息。

S409：解析cluster_info.json文件。

验证通过后，解析cluster_info.json文件得到多个组件间的耦合关系。

S410：生成安装关系。

根据多个组件间的耦合关系，将待创建集群所需的多个组件中至少两个具有所述耦合关系的组件分配至不同的主机中，从而得到多个组件和多个主机间的安装关系。

通过自动部署为用户在创建集群的过程中增加了便利性。

S411：请求ambari-sever获取服务组件信息。

S412：选择服务组件。

用户可以从返回的服务组件信息中手动选择服务组件，从而得到用户选择的服务组件。

通过手动部署为用户在创建集群的过程中增加了灵活性。

S413：输入主机标识。

用户可以从能够创建待创建集群的多个主机中，通过输入主机标识选择部分主机进行本次创建。

S414：生成安装关系。

根据用户选择的服务组件、多个主机等，结合多个组件间的耦合关系，将待创建集群所需的多个组件中至少两个具有所述耦合关系的组件分配至所选定的不同的主机中，从而得到多个组件和多个主机间的安装关系。

S415：生成蓝图。

根据手动或自动生成的安装关系生成多个主机分别对应的蓝图。

S416：在多个主机中分别安装ambari-agent。

S417：通过ambari-agent将蓝图分别注册到ambari-sever中。

S418：调用ambari接口，创建待创建集群。

调用ambari接口，根据多个主机分别对应的蓝图将多个组件分别安装至多个主机中，以得到待创建集群。

S419：结束。

作为一种可能的实现方式，S401-S419可以基于以下架构实现。

参见图5，该图为本申请实施例提供的一种集群创建的架构图。在图5中，该架构包括基础层510、业务层520和接口层530。其中，基础层510包括执行脚本(shell)511、数据库522、外部接口调用513。业务层520包括安装ambari-sever521、ambari-sever设置和开始(setup&&start)522、安装ambari-agent523、ambari-agent开始(start)524、注册服务(service)525、注册主机标识(hosts)526、分配主机527、生成蓝图528、请求服务(service)529、创建待创建集群5210、注册蓝图5211。接口层530提供REST API，REST API也称为RESTful API，是遵循REST架构规范的应用编程接口(API或Web API)，支持与RESTful Web服务进行交互。

作为一种可能的实现方式，本申请实施例提供获取用于待创建集群创建的主机的方式。下面以两种方式为例进行说明。

方式一：获取多个主机标识，根据多个主机标识确定多个主机。

在实际应用中，可以通过与服务器连接的终端设备提示用户输入主机标识，然后获取到用户输入的主机标识，该主机标识用于标识主机，从而通过主机标识确定出创建待创建集群所需的主机。

方式二：根据耦合关系从多个候选主机中确定出多个主机。

其中，候选主机为能够创建待创建集群的主机，根据耦合关系自动从多个候选主机中确定出多个主机，以便根据耦合关系尽量将具有耦合关系的组件分配至不同的主机中。

作为一种可能的实现方式，本申请实施例还提供一种展示搭建进度的方式，具体参见G1-G4：

G1：获取待创建集群的标识。

在创建待创建集群后，后台脚本服务可以从相应的后台进程服务获取待创建集群的标识，并返回该待创建集群的标识给用户，以便用户通过标识查询该待创建集群的搭建进度。

G2：获取搭建进度请求。

其中，搭建进度请求携带待创建集群的标识。在实际应用中，用户可以在终端设备中输入待创建集群的标识，并点击请求按钮，从而终端设备生成搭建进度请求给后台脚本服务。

G3：根据待创建集群的标识不断获取待创建集群的搭建进度。

后台脚本服务根据待创建集群的标识不断向后台进程服务获取该待创建集群的搭建进度，并发送给终端设备，以便终端设备展示给用户。

G4：向用户展示搭建进度。

由此，通过向用户展示搭建进度，即提供了可视化部署方案，让待创建集群的创建过程所见即所得，提高用户的体验感。

作为一种可能的实现方式，由于不同集群之间存在数据孤岛，需要对内部数据进行跨部门、跨网络、跨系统等集群的整合，然后对内部外部统一提供服务。例如，业务层面某些hive表格落在不同集群的数据需要联合运算的时候，需要把这部分数据迁移到集群内，不仅浪费存储，而且会加剧集群的数据规模。基于此，本申请实施例为多个集群搭建计算层和数据层，依据存算分离的架构，通过跨数据源、跨数据中心、跨计算引擎的大数据SQL引擎将内部数据进行统一的汇聚，帮助用户完成屏蔽计算引擎、版本差异，减少企业客户初始投入。

具体地，获取多个待创建集群，根据多个待创建集群创建存储层和计算层。其中，多个待创建集群为想要进行数据共享的多个集群，存储层根据多个待创建集群分别包括的主机的存储资源得到，计算层根据多个待创建集群分别包括的主机的计算资源得到。例如，基于数据WeDate的实时数据集成工具对数据进行统一汇聚，可选数据开发工具对数据进行处理和加工，然后数据统一存储在大数据引擎中，同时大数据引擎提供计算和分析能力，分析结果通过数据服务平台对外进行共享和交换。

由此，通过计算层和存储层分离，计算层划分一个个隔离的计算集，集群之间完全隔离。一个计算集群内部采用自己实现的mpp架构计算引擎，将数据hash分片到各个计算节点后并行处理来解决海量计算问题。此外，计算和存储都可以弹性扩展，组件都是来源于社区，同时对业界标准的友商组件也能够支持。同时支持扩容到上万节点的大规模集群并且满足弹性稳定、同时支持多种计算引擎满足上层需要，通过测试性能不输存算一体。

作为一种可能的实现方式，多个主机中至少一个主机包括用于实现存储服务的组件具有多个控制节点。由于相关技术中，用于实现存储服务的组件均采用hdfs组件，但是hdfs组件不是无限扩展的。经过研究发现，hdfs组件不能无限扩展的原因是其仅具有一个控制节点，虽然具有多个工作节点，但受限于一个控制节点的控制，使得hdfs组件不能无限扩展。基于此，本申请实施例通过为实现存储服务的组件增加控制节点，即从一个控制节点变为多个控制节点，从而打破限制，使得用于实现存储服务的组件能够无限扩展，即存储层采用可以弹性无限扩展的对象存储，进而实现无限扩容。

作为一种可能的实现方式，计算层包括通过开源的虚拟分布式文件系统alluxio构建的计算加速层。例如，hdfs/yarn存算分离在引入alluxio做计算加速层，对于计算数据量比较大、io密集型的任务提升效果约2倍左右(命中部分缓存，100％命中缓存情况下有些sql能达到4倍加速)，而且对于集群数据量规模大的集群，alluxio能减轻hdfs的压力和不稳定。

参见图6，该图为本申请实施例提供的一种存算分离的架构图。在图6中，包括存储层、元数据层和计算层，其中，计算层包括计算资源层、计算加速成和计算引擎层。下面分别进行说明。

(1)存储层：优先采用可以弹性无限扩展的对象存储，如Ozone，还可以根据用户需求选择hdfs、s3、cos、其他厂商的标准对象存储等。

(2)元数据层：支持数据湖的表格式，解决海量元数据存储，海量元数据服务和存储架构支持动态扩缩容。

(3)计算资源层：计算引擎都提交到kubernetes(简称k8s)集群上计算，通过Yarn提供统一的资源管理和调度能力。

(4)计算加速层：k8s集群的每个节点都有alluxio worker和alluxio fuse，以daemon set的部署方式做计算本地缓存加速。

(5)计算引擎层：提供presto、spark、flink等多种计算组件。

作为一种可能的实现方式，本申请实施例还提供一种获取组件配置信息的具体实现方式，具体参见H1-H3：

H1：获取登陆请求。

其中，登陆请求中携带用于标识业务需求的用户信息，如用户信息可以用户的登陆名，用户通过还登陆名可以从服务器购买业务需求所需的服务，由此，通过登陆名能够体现出该用户的业务需求。

H2：根据登陆请求获取多个基础组件。

根据登陆请求获取当前硬件环境中的所包括的基础组件。

H3：根据用户信息将多个基础组件进行封装，得到组件列表，以便根据组件列表获取组件配置信息。

在实际应用中，用户通过终端设备输入登录名，该登陆名能够体现该用户的业务需求。从而终端设备将携带登录名的邓秋请求发送给后台脚本服务，后台脚本服务将登陆请求发送给后台进程服务，以便获取当前硬件环境中所包括的所有基础组件。后台脚本服务在获取后台进程服务返回的基础组件后，根据登录名提下的用于需求，对基础组件进行封装，得到包括多个组件的组件列表。后台脚本服务器将组件列表发送给终端设备，以便用户根据组件列表输入组件配置信息。

作为一种可能的实现方式，本申请实施例还提供一种安装关系的具体实现方式，具体参见I1-I4：

I1：根据耦合关系，将至少两个具有耦合关系的组件分配至不同的主机中，得到多个组件和多个主机间待定安装关系。

I2：展示待定安装关系。

I3：获取针对于待定安装关系的修改信息。

I4：根据修改信息，生成安装关系。

在实际应用中，后台脚本服务根据耦合关系得到待定安装关系，并将待定安装关系发送给终端设备进行展示，用户基于待定安装关系进行修改，终端设备将用户针对于待定安装关系的丢该信息发送给后台脚本服务，以便后台脚本服务根据修改信息生成多个组件和多个主机间的安装关系。

为了便于进一步理解本申请实施例提供的技术方案，下面以本申请实施例提供的集群的创建方法的执行主体为服务器，对该集群的创建方法进行整体示例性介绍。其中，终端设备中安装与云服务器通讯的客户端，客户端用于展示创建集群的窗口界面，云服务器用于通过后台脚本服务和后台进程服务实现集群的创建。

下面先以用户的角度对集群的创建过程进行说明。

参见图7a-图7h，均为本申请实施例提供的一种集群的创建过程的示意图。

在图7a中，提供了“开始创建集群”的按钮，以便提示用户可以开始创建集群。当用户点击后，页面跳转至图7b。

在图7b中，会提示“请输入待创建集群的名称”，当用户输入后，页面跳转至图7c。

在图7c中，会展示组件列表，以便用户选择组件，在用户选择组件后，会让用户选择组件的版本，之后页面跳转至图7d。

在图7d中，会提示用户输入证书信息，用户输入证书信息后页面跳转至图7e。

在图7e中，会提示用户输入主机标识，以便从多个候选主机中确定出用于创建集群的多个主机。在输入主机标识后页面还可以选择程序、配置ssh用户和端口等(未示出)，然后跳转至图7f。

在图7f中，可以根据页面的提示选择服务组件。后续还可以分配控制节点、分配工作节点等(未示出)。

在图7g中，会展示给用户待定安装关系，以便用户针对待定安装信息进行修改或确认等，如允许用户自定义一些服务组件所需的服务参数。还可以通过页面让用户再次检查安装关系(未示出)。

在图7h中，在得到安装关系后，根据安装关系，将多个组件分别安装至多个主机中，以得到待创建集群。还可以进行测试等操作。

下面对集群的创建过程进行说明。

参加脑图8，该图为本申请实施例提供的一种待创建集群搭建的时序图。

S1：终端设备向后台脚本服务发送登陆请求。

S2：后台脚本服务向后台进程服务发送登陆请求。

S3：后台进程服务向后台脚本服务返回基础组件。

例如，hdfs、yarn、kafka等。

S4：后台脚本服务根据用户信息将多个基础组件进行封装，得到组件列表。

例如，将ambari返回的service解析，并根据单点登陆信息(case)不同，封装出不同的组件，此处使用到BASE_EANGINE,即封装了基础组件。

S5：后台脚本服务向终端设备发送组件列表。

S6：终端设备将用户输入的集群名称和选择对应的组件发送给后台脚本服务。

S7：后台脚本服务根据组件生成集群模型，并填充每个组件对应的服务组件。

S8：后台脚本服务将相关信息保存至数据库。

S9：终端设备将用户输入的主机标识发送给后台脚本服务。

S10：根据耦合关系，将至少两个具有耦合关系的组件分配至不同的主机中，得到待定安装关系。

S11：后台脚本服务将相关信息保存至数据库。

S12：后台脚本服务将待定安装关系发送终端设备。

S13：终端设备将用户输入的修改信息发送给后台脚本服务。

作为一种可能的实现方式，可以设置必选项和非必选项，其中必选项是用户无法修改的内容，非必选项是用户可以修改的选项。如前述表1中，通过Y表示的是必选项，通过N表示的是非必选项。

S14：后台脚本服务将相关信息保存至数据库。

S15：后台脚本服务根据修改信息生成安装关系，并生成蓝图。

S16：后台脚本服务调用ambari接口，注册蓝图到后台进程服务ambari-server中。

S17：后台脚本服务调用ambari接口，根据蓝图将多个组件分别安装至多个主机中，以得到待创建集群。

S18：后台进程服务返回集群ID(即集群标识)给后台脚本服务。

S19：后台脚本服务返回集群ID给终端设备。

S20：终端设备根据集群ID向后台脚本服务请求集群搭建进度。

S21：后台脚本服务根据集群ID向后台进程服务请求集群搭建进度。

S22：后台进程服务向后台脚本服务返回集群搭建进度。

S23：后台脚本服务向终端设备返回集群搭建进度。

通过上述技术方案，针对公有云场景和私有云场景和面对客户增长规模曲线的不同都有很好的支持，其中，对于私有云场景中的客户中小规模的集群在一定范围内成本优势，针对于公有云场景的客户的无限增长，也做到扩容到万节点的稳定体现系统健壮。

针对上文描述的集群的创建方法，本申请还提供了对应的集群的创建装置，以使上述集群的创建方法在实际中得以应用及实现。

参见图9，该图为本申请实施例提供的一种集群的创建装置的结构示意图。如图9所示，该集群的创建装置900包括：获取单元901、分配单元902和安装单元903；

所述获取单元901，用于获取组件配置参数，所述组件配置参数用于表征待创建集群所需的多个组件；

所述分配单元902，用于根据所述多个组件间的耦合关系，将至少两个具有所述耦合关系的组件分配至不同的主机中，得到所述多个组件和多个所述主机间的安装关系，所述主机为用于创建所述待创建集群的节点；

所述安装单元903，用于根据所述安装关系，将所述多个组件分别安装至多个所述主机中，以得到所述待创建集群。

作为一种可能的实现方式，所述分配单元902，具体用于：

根据所述耦合关系的强度或所述耦合关系的数量，对所述多个组件进行排序，得到组件顺序关系；

将所述多个组件按照所述组件顺序关系从大到小分别作为目标组件，将所述目标组件分配至目标主机中，将与所述目标组件具有所述耦合关系的组件分配至其他主机中，得到所述多个组件和多个所述主机间的安装关系；所述目标主机为当前还未与所述组件具有所述安装关系的主机中内存资源最大的主机，所述其他主机为多个所述主机中除所述目标主机外的主机。

作为一种可能的实现方式，所述多个组件包括实现存储服务的组件，所述实现存储服务的组件为所述多个组件中第一个作为所述目标组件的组件。

作为一种可能的实现方式，所述集群的创建装置900还包括裁剪单元，用于：

获取组件集合和业务需求，所述组件集合至少包括所述多个组件，所述组件包括多个用于实现不同功能的服务组件；

根据所述耦合关系和所述业务需求，从所述目标组件包括的多个服务组件中确定待删除服务组件，所述目标组件为所述组件集合中的一个组件，所述待删除服务组件为不受其他组件的影响，且对实现所述业务需求无用的服务组件；

从所述目标组件中裁剪所述待删除服务组件，得到针对于所述目标组件的轻量化组件；

所述安装单元903，具体用于：

获取所述多个组件分别对应的轻量化组件；

根据所述安装关系，将所述多个组件分别对应的轻量化组件分别安装至多个所述主机中，以得到所述待创建集群。

作为一种可能的实现方式，所述裁剪单元，具体用于：

从所述目标组件中裁剪所述待删除服务组件，得到初始轻量化组件；

为所述初始轻量化组件增加镜像服务组件，得到针对于所述目标组件的轻量化组件。

作为一种可能的实现方式，所述集群包括4个节点，所述分配单元902，具体用于：

根据所述耦合关系，将作为控制节点的服务组件和作为工作节点的服务组件分配至同一主机中，得到所述多个组件和多个所述主机间的安装关系。

作为一种可能的实现方式，所述分配单元902，具体用于：

获取当前已存在集群的组件安装情况；

根据所述耦合关系和所述组件安装情况，卸载有冲突组件并得到未安装组件，所述有冲突组件为安装在同一主机中具有所述耦合关系的组件，所述未安装组件为所述多个组件中还未安装的组件；

根据所述耦合关系，将至少两个具有所述耦合关系的未安装组件分配至不同的主机中，得到所述未安装组件和多个所述主机的安装关系。

作为一种可能的实现方式，所述集群的创建装置900还包括运维单元，用于：

获取证书信息，所述证书信息用于标识；

根据所述证书信息确定运维策略；

根据所述运维策略检测所述待创建集群的运行状况。

作为一种可能的实现方式，所述安装单元903，具体用于：

在多个所述主机中分别安装ambari-sever；

在多个所述主机中分别安装ambari-agent；

根据所述安装关系生成多个所述主机分别对应的蓝图，并通过多个所述主机中安装ambari-agent将多个所述主机分别对应的蓝图分别注册到多个所述主机中安装ambari-sever中；

调用ambari接口，根据多个所述主机分别对应的蓝图将所述多个组件分别安装至多个所述主机中，以得到所述待创建集群。

作为一种可能的实现方式，所述获取单元901，具体用于：

获取多个主机标识；

根据多个所述主机标识确定多个所述主机；或者，

根据所述耦合关系从多个候选主机中确定多个所述主机。

作为一种可能的实现方式，所述集群的创建装置900还包括展示单元，用于：

获取所述待创建集群的标识；

获取搭建进度请求，所述搭建进度请求携带所述待创建集群的标识；

根据所述待创建集群的标识不断获取所述待创建集群的搭建进度；

向用户展示所述搭建进度。

作为一种可能的实现方式，所述集群的创建装置900还包括创建单元，用于：

获取多个所述待创建集群；

根据多个所述待创建集群创建存储层和计算层，所述存储层根据多个所述待创建集群分别包括的主机的存储资源得到，所述计算层根据多个所述待创建集群分别包括的主机的计算资源得到。

作为一种可能的实现方式，所述多个所述主机中至少一个主机包括用于实现存储服务的组件具有多个控制节点。

作为一种可能的实现方式，所述计算层包括通过开源的虚拟分布式文件系统alluxio构建的计算加速层。

作为一种可能的实现方式，所述集群的创建装置900还包括封装单元，用于：

获取登陆请求，所述登陆请求中携带用于标识业务需求的用户信息；

根据所述登陆请求获取多个基础组件；

根据所述用户信息将所述多个基础组件进行封装，得到所述组件列表，以便根据所述组件列表获取所述组件配置信息。

作为一种可能的实现方式，所述分配单元902，具体用于：

根据所述耦合关系，将至少两个具有所述耦合关系的组件分配至不同的主机中，得到所述多个组件和多个所述主机间待定安装关系；

展示所述待定安装关系；

获取针对于所述待定安装关系的修改信息；

根据所述修改信息，生成所述安装关系。

由上述技术方案可以看出，获取组件配置参数，组件配置参数用于表征待创建集群创建所需的多个组件。根据多个组件间的耦合关系，将至少两个具有耦合关系的组件分配至不同的主机中。其中，耦合关系能够体现两个组件间是否相互影响，将相互影响的两个组件分配至不同的主机中，实现组件之间的相互隔离，能够降低具有耦合关系的组件恶意争抢同一个主机的硬件资源，提高集群性能。从而依据耦合关系得到多个组件和多个主机间的安装关系，根据该安装关系，将多个组件分别安装至多个主机中，进而得到待创建集群。由此，仅需组件配置参数，依据耦合关系将组件配置参数对应的多个组件分别安装至多个主机中，不仅实现了集群的自动创建，还实现组件间的相互隔离，降低恶意争抢底层硬件资源的概率，提高了集群的性能。

本申请实施例还提供了一种计算机设备，该计算机设备为前述介绍的计算机设备，该计算机设备可以为服务器或者终端设备，前述所述的集群的创建装置可以内置于服务器或终端设备中，下面将从硬件实体化的角度对本申请实施例提供的计算机设备进行介绍。其中，图10所示为服务器的结构示意图，图11所示为终端设备的结构示意图。

参见图10，该图为本申请实施例提供的一种服务器结构示意图，该服务器1400可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器1422，如中央处理器(Central Processing Units，CPU)，存储器1432，一个或一个以上应用程序1442或数据1444的存储介质1430(例如一个或一个以上海量存储设备)。其中，存储器1432和存储介质1430可以是短暂存储或持久存储。存储在存储介质1430的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，处理器1422可以设置为与存储介质1430通信，在服务器1400上执行存储介质1430中的一系列指令操作。

服务器1400还可以包括一个或一个以上电源1426，一个或一个以上有线或无线网络接口1450，一个或一个以上输入输出接口1458，和/或，一个或一个以上操作系统1441，例如Windows Server^TM，Mac OS X^TM，Unix^TM,Linux^TM，FreeBSD^TM等等。

上述实施例中由服务器所执行的步骤可以基于该图10所示的服务器结构。

其中，CPU 1422用于执行如下步骤：

获取组件配置参数，所述组件配置参数用于表征待创建集群所需的多个组件；

根据所述多个组件间的耦合关系，将至少两个具有所述耦合关系的组件分配至不同的主机中，得到所述多个组件和多个所述主机间的安装关系，所述主机为用于创建所述待创建集群的节点；

根据所述安装关系，将所述多个组件分别安装至多个所述主机中，以得到所述待创建集群。

可选的，CPU 1422还可以执行本申请实施例中集群的创建方法任一具体实现方式的方法步骤。

参见图11，该图为本申请实施例提供的一种终端设备的结构示意图。图11示出的是与本申请实施例提供的终端设备相关的智能手机的部分结构的框图，该智能手机包括：射频(Radio Frequency，简称RF)电路1510、存储器1520、输入单元1530、显示单元1540、传感器1550、音频电路1560、无线保真(简称WiFi)模块1570、处理器1580、以及电源1590等部件。本领域技术人员可以理解，图11中示出的智能手机结构并不构成对智能手机的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

下面结合图11对智能手机的各个构成部件进行具体的介绍：

RF电路1510可用于收发信息或通话过程中，信号的接收和发送，特别地，将基站的下行信息接收后，给处理器1580处理；另外，将设计上行的数据发送给基站。

存储器1520可用于存储软件程序以及模块，处理器1580通过运行存储在存储器1520的软件程序以及模块，从而实现智能手机的各种功能应用以及数据处理。

输入单元1530可用于接收输入的数字或字符信息，以及产生与智能手机的用户设置以及功能控制有关的键信号输入。具体地，输入单元1530可包括触控面板1531以及其他输入设备1532。触控面板1531，也称为触摸屏，可收集用户在其上或附近的触摸操作，并根据预先设定的程式驱动相应的连接装置。除了触控面板1531，输入单元1530还可以包括其他输入设备1532。具体地，其他输入设备1532可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

显示单元1540可用于显示由用户输入的信息或提供给用户的信息以及智能手机的各种菜单。显示单元1540可包括显示面板1541，可选的，可以采用液晶显示器(LiquidCrystal Display，简称LCD)、有机发光二极管(Organic Light-Emitting Diode，简称OLED)等形式来配置显示面板1541。

智能手机还可包括至少一种传感器1550，比如光传感器、运动传感器以及其他传感器。至于智能手机还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

音频电路1560、扬声器1561，传声器1562可提供用户与智能手机之间的音频接口。音频电路1560可将接收到的音频数据转换后的电信号，传输到扬声器1561，由扬声器1561转换为声音信号输出；另一方面，传声器1562将收集的声音信号转换为电信号，由音频电路1560接收后转换为音频数据，再将音频数据输出处理器1580处理后，经RF电路1510以发送给比如另一智能手机，或者将音频数据输出至存储器1520以便进一步处理。

处理器1580是智能手机的控制中心，利用各种接口和线路连接整个智能手机的各个部分，通过运行或执行存储在存储器1520内的软件程序和/或模块，以及调用存储在存储器1520内的数据，执行智能手机的各种功能和处理数据。可选的，处理器1580可包括一个或多个处理单元。

智能手机还包括给各个部件供电的电源1590(比如电池)，优选的，电源可以通过电源管理系统与处理器1580逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。

尽管未示出，智能手机还可以包括摄像头、蓝牙模块等，在此不再赘述。

在本申请实施例中，该智能手机所包括的存储器1520可以存储程序代码，并将所述程序代码传输给所述处理器。

该智能手机所包括的处理器1580可以根据所述程序代码中的指令执行上述实施例提供的集群的创建方法。

本申请实施例还提供一种计算机可读存储介质，用于存储计算机程序，该计算机程序用于执行上述实施例提供的集群的创建方法。

本申请实施例还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述方面的各种可选实现方式中提供的集群的创建方法。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质可以是下述介质中的至少一种：只读存储器(英文：Read-Only Memory，缩写：ROM)、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备及系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的设备及系统实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述，仅为本申请的一种具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。本申请在上述各方面提供的实现方式的基础上，还可以进行进一步组合以提供更多实现方式。因此，本申请的保护范围应该以权利要求的保护范围为准。

Claims (15)

1.一种集群的创建方法，其特征在于，所述方法包括：

获取组件配置参数，所述组件配置参数用于表征待创建集群所需的多个组件；

根据所述多个组件间的耦合关系，将至少两个具有所述耦合关系的组件分配至不同的主机中，得到所述多个组件和多个所述主机间的安装关系，所述主机为用于创建所述待创建集群的节点；

根据所述安装关系，将所述多个组件分别安装至多个所述主机中，以得到所述待创建集群。

2.根据权利要求1所述的方法，其特征在于，所述根据所述多个组件间的耦合关系，将至少两个具有所述耦合关系的组件分配至不同的主机中，得到所述多个组件和多个所述主机间的安装关系，包括：

根据所述耦合关系的强度或所述耦合关系的数量，对所述多个组件进行排序，得到组件顺序关系；

将所述多个组件按照所述组件顺序关系从大到小分别作为目标组件，将所述目标组件分配至目标主机中，将与所述目标组件具有所述耦合关系的组件分配至其他主机中，得到所述多个组件和多个所述主机间的安装关系；所述目标主机为当前还未与所述组件具有所述安装关系的主机中内存资源最大的主机，所述其他主机为多个所述主机中除所述目标主机外的主机。

3.根据权利要求2所述的方法，其特征在于，所述多个组件包括实现存储服务的组件，所述实现存储服务的组件为所述多个组件中第一个作为所述目标组件的组件。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

获取组件集合和业务需求，所述组件集合至少包括所述多个组件，所述组件包括多个用于实现不同功能的服务组件；

根据所述耦合关系和所述业务需求，从所述目标组件包括的多个服务组件中确定待删除服务组件，所述目标组件为所述组件集合中的一个组件，所述待删除服务组件为不受其他组件的影响，且对实现所述业务需求无用的服务组件；

从所述目标组件中裁剪所述待删除服务组件，得到针对于所述目标组件的轻量化组件；

所述根据所述安装关系，将所述多个组件分别安装至多个所述主机中，以得到所述待创建集群，包括：

获取所述多个组件分别对应的轻量化组件；

根据所述安装关系，将所述多个组件分别对应的轻量化组件分别安装至多个所述主机中，以得到所述待创建集群。

5.根据权利要求4所述的方法，其特征在于，所述从所述目标组件中裁剪所述待删除服务组件，得到针对于所述目标组件的轻量化组件，包括：

从所述目标组件中裁剪所述待删除服务组件，得到初始轻量化组件；

为所述初始轻量化组件增加镜像服务组件，得到针对于所述目标组件的轻量化组件。

6.根据权利要求1所述的方法，其特征在于，所述集群包括4个节点，所述根据所述多个组件间的耦合关系，将至少两个具有所述耦合关系的组件分配至不同的主机中，得到所述多个组件和多个所述主机间的安装关系，包括：

根据所述耦合关系，将作为控制节点的服务组件和作为工作节点的服务组件分配至同一主机中，得到所述多个组件和多个所述主机间的安装关系。

7.根据权利要求1所述的方法，其特征在于，所述根据所述多个组件间的耦合关系，将至少两个具有所述耦合关系的组件分配至不同的主机中，得到所述多个组件和多个所述主机间的安装关系，包括：

获取当前已存在集群的组件安装情况；

根据所述耦合关系和所述组件安装情况，卸载有冲突组件并得到未安装组件，所述有冲突组件为安装在同一主机中具有所述耦合关系的组件，所述未安装组件为所述多个组件中还未安装的组件；

根据所述耦合关系，将至少两个具有所述耦合关系的未安装组件分配至不同的主机中，得到所述未安装组件和多个所述主机的安装关系。

8.根据权利要求1所述的方法，其特征在于，所述方法还包括：

获取证书信息，所述证书信息用于标识；

根据所述证书信息确定运维策略；

根据所述运维策略检测所述待创建集群的运行状况。

9.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在多个所述主机中分别安装ambari-sever；

所述根据所述安装关系，将所述多个组件分别安装至多个所述主机中，以得到所述待创建集群，包括：

在多个所述主机中分别安装ambari-agent；

根据所述安装关系生成多个所述主机分别对应的蓝图，并通过多个所述主机中安装ambari-agent将多个所述主机分别对应的蓝图分别注册到多个所述主机中安装ambari-sever中；

调用ambari接口，根据多个所述主机分别对应的蓝图将所述多个组件分别安装至多个所述主机中，以得到所述待创建集群。

10.根据权利要求1所述方法，其特征在于，所述方法还包括：

获取所述待创建集群的标识；

获取搭建进度请求，所述搭建进度请求携带所述待创建集群的标识；

根据所述待创建集群的标识不断获取所述待创建集群的搭建进度；

向用户展示所述搭建进度。

11.根据权利要求1所述的方法，其特征在于，所述方法还包括：

获取多个所述待创建集群；

根据多个所述待创建集群创建存储层和计算层，所述存储层根据多个所述待创建集群分别包括的主机的存储资源得到，所述计算层根据多个所述待创建集群分别包括的主机的计算资源得到。

12.一种集群的创建装置，其特征在于，所述装置包括：获取单元、分配单元和安装单元；

所述获取单元，用于获取组件配置参数，所述组件配置参数用于表征待创建集群所需的多个组件；

所述分配单元，用于根据所述多个组件间的耦合关系，将至少两个具有所述耦合关系的组件分配至不同的主机中，得到所述多个组件和多个所述主机间的安装关系，所述主机为用于创建所述待创建集群的节点；

所述安装单元，用于根据所述安装关系，将所述多个组件分别安装至多个所述主机中，以得到所述待创建集群。

13.一种计算机设备，其特征在于，所述计算机设备包括处理器以及存储器：

所述存储器用于存储计算机程序，并将所述计算机程序传输给所述处理器；

所述处理器用于根据所述计算机程序中的指令执行权利要求1-11中任意一项所述的方法。

14.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质用于存储计算机程序，所述计算机程序用于执行权利要求1-11中任意一项所述的方法。

15.一种包括计算机程序的计算机程序产品，其特征在于，当其在计算机设备上运行时，使得所述计算机设备执行权利要求1-11中任意一项所述的方法。