一种OpenStack部署方法、装置、设备及介质与流程

本申请涉及云技术领域，特别涉及一种openstack部署方法、装置、设备及介质。

背景技术：

openstack是一个旨在为公共及私有云的建设与管理提供软件的开源项目，由计算、存储、网络等几个主要的组件组合起来完成云计算管理工作，其目标是为全球数以亿计的用户提供实施简单、可大规模扩展、丰富、标准统一的云计算管理平台。

openstack平台基于多租户模式，多个租户通过统一的openstack平台进行服务的定制与使用。在openstack实际生产环境中，由于涉及大规模用户并发、容灾、高可用等性能需求，openstack平台通常采用分布式、多业务节点的部署方式。

然而，服务提供方在部署前期往往疏于规划，容易出现以下情形：部署过程中业务节点占用过多不必要的硬件资源，导致了硬件成本不必要的增减；或由于硬件资源不足或是业务节点不能满足实际生产需求等因素导致在openstack平台运行期间不得不进行再调整、重规划的情况。这样造成了大量人力的返工和不必要成本的投入，降低了openstack平台的服务质量和用户体验。

技术实现要素：

有鉴于此，本申请的目的在于提供一种openstack部署方法、装置、设备及介质，能够提升openstack平台部署的合理性，使得在能够满足所有业务需求的同时，降低了服务提供方的硬件成本总耗费。其具体方案如下：

第一方面，本申请公开了一种openstack部署方法，包括：

确定openstack平台中所有租户的业务需求，以得到租约集合；

确定与所述租约集合中每个业务需求对应的openstack业务节点类型，得到与所述租约集合对应的所有待部署的业务节点类型集合；

确定当前服务提供方所有能够用于提供服务的物理服务器类型集合；

根据所述业务节点类型集合中每种openstack业务节点类型对应的硬件资源需求和所述物理服务器类型集合中每种物理服务器类型对应的硬件资源提供能力，并以部署后所述租约集合中的所有业务需求均能得到满足并且所述服务提供方的硬件成本总耗费最小为优化目标，确定相应的部署参数；其中，所述部署参数包括所述业务节点类型集合中每种类型的openstack业务节点的第一部署数量需求、所述物理服务器类型集合中每种类型的物理服务器的第二部署数量需求以及目标映射关系；所述目标映射关系为所述租约集合、与所述第一部署数量需求对应的所有openstack业务节点的实例集合以及与所述第二部署数量需求对应的所有物理服务器的实例集合之间的映射关系；

根据所述部署参数，部署相应的openstack平台。

可选的，所述确定与所述租约集合中每个业务需求对应的openstack业务节点类型，包括：

根据预设的业务需求与openstack业务节点类型之间的映射关系，确定与所述租约集合中每个业务需求对应的openstack业务节点类型。

可选的，所述硬件资源需求包括cpu资源需求、内存资源需求和存储资源需求；

相应的，所述硬件资源提供能力包括cpu资源提供能力、内存资源提供能力和存储资源提供能力。

可选的，若所述服务提供方自有基础设施能够提供充足的硬件资源，则所述优化目标包括：

在保证所述租约集合中的所有业务需求均能得到满足的前提下，确保自有物理服务器的使用数量最少。

可选的，若所述服务提供方自有基础设施无法提供充足的硬件资源，则所述优化目标包括：

在保证所述租约集合中的所有业务需求均能得到满足的前提下，优先使用自有物理服务器，并确保租用的物理服务器的数量最少。

可选的，若所述服务提供方当前没有用于提供硬件资源的自有基础设施，则所述优化目标包括：

在保证所述租约集合中的所有业务需求均能得到满足的前提下，确保租用的物理服务器的数量最少。

可选的，确定所述目标映射关系的过程，包括：

采用遗传算法，确定所述目标映射关系。

第二方面，本申请公开了一种openstack部署装置，包括：

业务需求确定模块，用于确定openstack平台中所有租户的业务需求，以得到租约集合；

业务节点类型确定模块，用于确定与所述租约集合中每个业务需求对应的openstack业务节点类型，得到与所述租约集合对应的所有待部署的业务节点类型集合；

服务器类型确定模块，用于确定当前服务提供方所有能够用于提供服务的物理服务器类型集合；

部署参数确定模块，用于根据所述业务节点类型集合中每种openstack业务节点类型对应的硬件资源需求和所述物理服务器类型集合中每种物理服务器类型对应的硬件资源提供能力，并以部署后所述租约集合中的所有业务需求均能得到满足并且所述服务提供方的硬件成本总耗费最小为优化目标，确定相应的部署参数；其中，所述部署参数包括所述业务节点类型集合中每种类型的openstack业务节点的第一部署数量需求、所述物理服务器类型集合中每种类型的物理服务器的第二部署数量需求以及目标映射关系；所述目标映射关系为所述租约集合、与所述第一部署数量需求对应的所有openstack业务节点的实例集合以及与所述第二部署数量需求对应的所有物理服务器的实例集合之间的映射关系；

平台部署模块，用于根据所述部署参数，部署相应的openstack平台。

第三方面，本申请公开了一种openstack部署设备，包括：

存储器，用于保存计算机程序；

处理器，用于执行所述计算机程序，以实现前述公开的openstack部署方法。

第四方面，本申请公开了一种计算机可读存储介质，用于保存计算机程序，其中，所述计算机程序被处理器执行时实现前述公开的openstack部署方法。

可见，本申请先确定了openstack平台中所有租户的业务需求，以得到租约集合，然后确定与所述租约集合中每个业务需求对应的openstack业务节点类型，得到与所述租约集合对应的所有待部署的业务节点类型集合，并确定当前服务提供方所有能够用于提供服务的物理服务器类型集合；接着根据所述业务节点类型集合中每种openstack业务节点类型对应的硬件资源需求和所述物理服务器类型集合中每种物理服务器类型对应的硬件资源提供能力，并以部署后所述租约集合中的所有业务需求均能得到满足并且所述服务提供方的硬件成本总耗费最小为优化目标，确定相应的部署参数；最后根据所述部署参数，部署相应的openstack平台。由此可知，本申请具体是以部署后所述租约集合中的所有业务需求均能得到满足并且所述服务提供方的硬件成本总耗费最小为优化目标，来确定出最终的部署参数的，这样可以使得部署后所得到的openstack平台能够满足所有租户的业务需求，与此同时，可以使得服务提供方的硬件成本总耗费最小。综上，本申请能够提升openstack平台部署的合理性，使得在能够满足所有业务需求的同时，降低了服务提供方的硬件成本总耗费。

附图说明

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

图1为本申请公开的一种openstack部署方法流程图；

图2为openstack平台模型示意图；

图3为openstack平台部署示意图；

图4为本申请公开的一种具体的openstack部署方法流程图；

图5为本申请公开的一种具体的openstack部署方法流程图；

图6为本申请公开的一种具体的openstack部署方法流程图；

图7为本申请公开的一种openstack部署装置结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

参见图1所示，本申请实施例公开了一种openstack部署方法，包括：

步骤s11：确定openstack平台中所有租户的业务需求，以得到租约集合；

步骤s12：确定与所述租约集合中每个业务需求对应的openstack业务节点类型，得到与所述租约集合对应的所有待部署的业务节点类型集合；

步骤s13：确定当前服务提供方所有能够用于提供服务的物理服务器类型集合；

步骤s14：根据所述业务节点类型集合中每种openstack业务节点类型对应的硬件资源需求和所述物理服务器类型集合中每种物理服务器类型对应的硬件资源提供能力，并以部署后所述租约集合中的所有业务需求均能得到满足并且所述服务提供方的硬件成本总耗费最小为优化目标，确定相应的部署参数；其中，所述部署参数包括所述业务节点类型集合中每种类型的openstack业务节点的第一部署数量需求、所述物理服务器类型集合中每种类型的物理服务器的第二部署数量需求以及目标映射关系；所述目标映射关系为所述租约集合、与所述第一部署数量需求对应的所有openstack业务节点的实例集合以及与所述第二部署数量需求对应的所有物理服务器的实例集合之间的映射关系；

步骤s15：根据所述部署参数，部署相应的openstack平台。

也即，本实施例具体是以在所有业务需求均能被满足的前提下，保证服务提供方的硬件成本总耗费最少为优化目标的。本申请实施例具体可以根据上述步骤s14，构建相应的数学模型，以确定出相应的部署参数。可以理解的是，上述数学模型具体是属于携带有约束条件的组合优化问题。

另外，本实施例中的所述硬件资源需求具体可以包括cpu资源需求、内存资源需求和存储资源需求；相应的，所述硬件资源提供能力包括cpu资源提供能力、内存资源提供能力和存储资源提供能力。

进一步的，本申请实施例在确定所述目标映射关系时，优先采用人工智能算法来确定所述目标映射关系，例如采用遗传算法来确定所述目标映射关系。

需要指出的是，本申请实施例中，所有服务器的硬件资源和各业务节点均由服务提供方统一部署和管理，租户通过网络进行服务的定制和使用。参见图2所示，openstack平台自底向上分为：(1)基础设施层：由服务提供方统一提供，来源或是服务提供方自有的服务器设施资源，或是租用其它服务提供方的服务器设施资源；(2)服务层：提供openstack平台稳定高性能运行所需的各业务节点，由计算节点、存储节点、网络节点等相关业务节点组合而成；(3)调度层：通过openstack平台自带的用户请求响应控制和业务调度机制，将通过平台接收的多租户业务请求合理均衡下发到相关的openstack业务节点上，以实现各租户的业务需求，保证openstack平台高性能、高服务质量的运营。

基于图2的模型示意图，一种基于成本优化的openstack部署方法的示意图如附图3所示，租户1、租户2、租户3、租户4的租户请求分别涉及对应了openstack平台的业务节点类型os1、os2，服务提供方此时所用来部署openstack平台的基础设施(可以是服务提供方自有的基础设施、也可以是服务提供方租用的基础设施、又或者是既包括服务提供方自有的基础设施也包括服务提供方租用的基础设施)为3种服务器类型pm1、pm2、pm3，分别具有不同的资源规格和使用成本。在图3显示的部署方案中，服务提供方使用了2台pm1类型的服务器pm11、pm12，使用了2台pm2类型的服务器pm21、pm22，需要部署两个openstack节点类型为os1的实例os11、os12，两个openstack节点类型为os2的实例os21、os22，os11部署在pm11上，os12部署在pm12上，os21部署在pm21上，os22部署在pm22上。os11上对应了租户1的请求，os12上对应了租户2的请求，os21上对应了租户2、租户3的请求，os22上对应了租户4的请求。

可见，本申请实施例先确定了openstack平台中所有租户的业务需求，以得到租约集合，然后确定与所述租约集合中每个业务需求对应的openstack业务节点类型，得到与所述租约集合对应的所有待部署的业务节点类型集合，并确定当前服务提供方所有能够用于提供服务的物理服务器类型集合；接着根据所述业务节点类型集合中每种openstack业务节点类型对应的硬件资源需求和所述物理服务器类型集合中每种物理服务器类型对应的硬件资源提供能力，并以部署后所述租约集合中的所有业务需求均能得到满足并且所述服务提供方的硬件成本总耗费最小为优化目标，确定相应的部署参数；最后根据所述部署参数，部署相应的openstack平台。由此可知，本申请实施例具体是以部署后所述租约集合中的所有业务需求均能得到满足并且所述服务提供方的硬件成本总耗费最小为优化目标，来确定出最终的部署参数的，这样可以使得部署后所得到的openstack平台能够满足所有租户的业务需求，与此同时，可以使得服务提供方的硬件成本总耗费最小。综上，本申请实施例能够提升openstack平台部署的合理性，使得在能够满足所有业务需求的同时，降低了服务提供方的硬件成本总耗费。

参见图4所示，本申请实施例公开了一种具体的openstack部署方法，该方法具体是在服务提供方自有基础设施能够提供充足的硬件资源的情况下实施，具体包括：

步骤s21：确定openstack平台中所有租户的业务需求，以得到租约集合；

步骤s22：根据预设的业务需求与openstack业务节点类型之间的映射关系，确定与所述租约集合中每个业务需求对应的openstack业务节点类型，得到与所述租约集合对应的所有待部署的业务节点类型集合；

步骤s23：确定当前服务提供方自身拥有的所有能够用于提供服务的物理服务器类型集合；

步骤s24：根据所述业务节点类型集合中每种openstack业务节点类型对应的硬件资源需求和所述物理服务器类型集合中每种物理服务器类型对应的硬件资源提供能力，并以在保证所述租约集合中的所有业务需求均能得到满足的前提下，确保自有物理服务器的使用数量最少为优化目标，确定相应的部署参数；其中，所述部署参数包括所述业务节点类型集合中每种类型的openstack业务节点的第一部署数量需求、所述物理服务器类型集合中每种类型的物理服务器的第二部署数量需求以及目标映射关系；所述目标映射关系为所述租约集合、与所述第一部署数量需求对应的所有openstack业务节点的实例集合以及与所述第二部署数量需求对应的所有物理服务器的实例集合之间的映射关系；

步骤s25：根据所述部署参数，部署相应的openstack平台。

可见，本实施例是在服务提供方自有基础设施能够提供充足的硬件资源的情况下，以在保证所述租约集合中的所有业务需求均能得到满足的前提下，确保自有物理服务器的使用数量最少为优化目标，来确定相应的部署参数，通过上述优化目标，可以保证在能够满足所有业务需求的情况下，使得自有物理服务器的使用数量最小，以此降低了服务提供方的硬件成本总耗费。

参见图5所示，本申请实施例公开了一种具体的openstack部署方法，该方法具体是在服务提供方自有基础设施无法提供充足的硬件资源的情况下实施，具体包括：

步骤s31：确定openstack平台中所有租户的业务需求，以得到租约集合；

步骤s32：根据预设的业务需求与openstack业务节点类型之间的映射关系，确定与所述租约集合中每个业务需求对应的openstack业务节点类型，得到与所述租约集合对应的所有待部署的业务节点类型集合；

步骤s33：确定当前服务提供方自身拥有的以及能够租用的所有能够用于提供服务的物理服务器类型集合；

步骤s34：根据所述业务节点类型集合中每种openstack业务节点类型对应的硬件资源需求和所述物理服务器类型集合中每种物理服务器类型对应的硬件资源提供能力，并以在保证所述租约集合中的所有业务需求均能得到满足的前提下，优先使用自有物理服务器，并确保租用的物理服务器的数量最少为优化目标，确定相应的部署参数；其中，所述部署参数包括所述业务节点类型集合中每种类型的openstack业务节点的第一部署数量需求、所述物理服务器类型集合中每种类型的物理服务器的第二部署数量需求以及目标映射关系；所述目标映射关系为所述租约集合、与所述第一部署数量需求对应的所有openstack业务节点的实例集合以及与所述第二部署数量需求对应的所有物理服务器的实例集合之间的映射关系；

步骤s35：根据所述部署参数，部署相应的openstack平台。

可见，本申请实施例是在服务提供方自有基础设施无法提供充足的硬件资源的情况下，以在保证所述租约集合中的所有业务需求均能得到满足的前提下，优先使用自有物理服务器，并确保租用的物理服务器的数量最少为优化目标，来确定相应的部署参数，通过上述优化目标，可以保证在能够满足所有业务需求的情况下，优先使用自有的物理服务器，并租用一些物理服务器，并且确保租用的服务器的数量最少，以此实现在能够满足所有业务需求的同时，降低服务提供方的硬件成本总耗费的目的。

参见图6所示，本申请实施例公开了一种具体的openstack部署方法，该方法具体是在服务提供方当前没有用于提供硬件资源的自有基础设施的情况下实施，具体包括：

步骤s41：确定openstack平台中所有租户的业务需求，以得到租约集合；

步骤s42：根据预设的业务需求与openstack业务节点类型之间的映射关系，确定与所述租约集合中每个业务需求对应的openstack业务节点类型，得到与所述租约集合对应的所有待部署的业务节点类型集合；

步骤s43：确定当前服务提供方能够租用的所有能够用于提供服务的物理服务器类型集合；

步骤s44：根据所述业务节点类型集合中每种openstack业务节点类型对应的硬件资源需求和所述物理服务器类型集合中每种物理服务器类型对应的硬件资源提供能力，并以在保证所述租约集合中的所有业务需求均能得到满足的前提下，确保租用的物理服务器的数量最少为优化目标，确定相应的部署参数；其中，所述部署参数包括所述业务节点类型集合中每种类型的openstack业务节点的第一部署数量需求、所述物理服务器类型集合中每种类型的物理服务器的第二部署数量需求以及目标映射关系；所述目标映射关系为所述租约集合、与所述第一部署数量需求对应的所有openstack业务节点的实例集合以及与所述第二部署数量需求对应的所有物理服务器的实例集合之间的映射关系；

步骤s45：根据所述部署参数，部署相应的openstack平台。

可见，本申请实施例是在服务提供方当前没有用于提供硬件资源的自有基础设施的情况下，以在保证所述租约集合中的所有业务需求均能得到满足的前提下，确保租用的物理服务器的数量最少为优化目标，从而达到在能够满足所有业务需求的同时，降低服务提供方的硬件成本总耗费的目的。

参见图7所示，本申请实施例还公开一种openstack部署装置，包括：

业务需求确定模块11，用于确定openstack平台中所有租户的业务需求，以得到租约集合；

业务节点类型确定模块12，用于确定与所述租约集合中每个业务需求对应的openstack业务节点类型，得到与所述租约集合对应的所有待部署的业务节点类型集合；

服务器类型确定模块13，用于确定当前服务提供方所有能够用于提供服务的物理服务器类型集合；

部署参数确定模块14，用于根据所述业务节点类型集合中每种openstack业务节点类型对应的硬件资源需求和所述物理服务器类型集合中每种物理服务器类型对应的硬件资源提供能力，并以部署后所述租约集合中的所有业务需求均能得到满足并且所述服务提供方的硬件成本总耗费最小为优化目标，确定相应的部署参数；其中，所述部署参数包括所述业务节点类型集合中每种类型的openstack业务节点的第一部署数量需求、所述物理服务器类型集合中每种类型的物理服务器的第二部署数量需求以及目标映射关系；所述目标映射关系为所述租约集合、与所述第一部署数量需求对应的所有openstack业务节点的实例集合以及与所述第二部署数量需求对应的所有物理服务器的实例集合之间的映射关系；

平台部署模块15，用于根据所述部署参数，部署相应的openstack平台。

其中，关于上述各个模块更加具体的工作过程可以参考前述实施例中公开的相应内容，在此不再进行赘述。

可见，本申请先确定了openstack平台中所有租户的业务需求，以得到租约集合，然后确定与所述租约集合中每个业务需求对应的openstack业务节点类型，得到与所述租约集合对应的所有待部署的业务节点类型集合，并确定当前服务提供方所有能够用于提供服务的物理服务器类型集合；接着根据所述业务节点类型集合中每种openstack业务节点类型对应的硬件资源需求和所述物理服务器类型集合中每种物理服务器类型对应的硬件资源提供能力，并以部署后所述租约集合中的所有业务需求均能得到满足并且所述服务提供方的硬件成本总耗费最小为优化目标，确定相应的部署参数；最后根据所述部署参数，部署相应的openstack平台。由此可知，本申请具体是以部署后所述租约集合中的所有业务需求均能得到满足并且所述服务提供方的硬件成本总耗费最小为优化目标，来确定出最终的部署参数的，这样可以使得部署后所得到的openstack平台能够满足所有租户的业务需求，与此同时，可以使得服务提供方的硬件成本总耗费最小。综上，本申请能够提升openstack平台部署的合理性，使得在能够满足所有业务需求的同时，降低了服务提供方的硬件成本总耗费。

进一步的，本申请还公开了一种openstack部署设备，包括：

存储器，用于保存计算机程序；

处理器，用于执行所述计算机程序，以实现前述实施例公开的openstack部署方法。

进一步的，本申请还公开了一种计算机可读存储介质，用于保存计算机程序，其中，所述计算机程序被处理器执行时实现前述实施例公开的openstack部署方法。

其中，关于上述方法的具体步骤可以参考前述实施例公开的相应内容，在此不再进行赘述。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd-rom、或技术领域内所公知的任意其它形式的存储介质中。

以上对本申请所提供的一种openstack部署方法、装置、设备及介质进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。