一种云节点混合部署方法与流程

本发明涉及计算机
技术领域：
，尤其涉及一种云节点混合部署方法。
背景技术：
：目前我们对外提供的存储服务形式主要有块存储、第三方存储、本地存储、对象存储。上述存储服务使用完全独立的服务器部署都没有问题，但当共享某个节点进行混合部署时往往出现问题。这里面，由于计算节点的职能，以及我们默认超融合存储方案的设定，块存储是这些存储产品的核心。考虑混合部署都要考虑到对块存储产品的影响和适配，支持块存储和第三方存储混合部署，支持块存储和本地存储混合部署，但对象存储和块存储角色还不支持混合部署。目前提供了基于tusdfs的块存储管理，使用tusdfs作为后端存储，默认的服务器规模需要提供3+3(3控制节点，3计算节点)拓扑部署，如果考虑加入对象存储的功能支持，那么需要提供3+3+3(3控制节点，3计算节点，3对象存储节点)的服务器规模。但是面对用户的差异性，当用户职能提供有限的3+3或者1+3机器规模，功能上还要求全面使用块存储、对象存储功能就会出现不能满足的情况。这种情况下，支持块存储和对象存储的混合部署就显得尤为必要。技术实现要素：有鉴于现有技术的上述缺陷，本发明所要解决的技术问题是提供一种云节点混合部署方法，以解决现有技术的不足。为实现上述目的，本发明提供了一种云节点混合部署方法，包括以下步骤：步骤1、节点部署，选取目标节点，首先配置网络信息，为目标节点选择网络类型和网卡信息；发现磁盘操作，在部署节点之前先发现磁盘，用户进行磁盘初始化的操作和选择对象存储；部署服务，开始部署工作；磁盘特征标记，部署节点时磁盘信息带有部署节点角色的特征；后续添加磁盘，节点部署如果有剩余的空闲磁盘，之后在节点部署处选择添加磁盘给某种角色；步骤2、发现磁盘环节，先执行发现磁盘操作，接下来再根据用途进行有针对性的磁盘格式化操作；步骤3、块存储集群扩容，从所有节点上选择purpose为block_device的若干磁盘，完成扩容，更新novastorage_disks表的disk状态；步骤4、对象存储集群扩容，从所有节点上选择purpose为object_store的若干磁盘，完成扩容，更新novastorage_disks表的disk状态和tuscloudos中object_store_disks表的状态；步骤5、块存储踢盘缩容，对tusdfs进程的操作，确定选择磁盘是否继续服务于所属的集群；步骤6、对象存储踢盘缩容，对accountring，objectring以及containerring的操作，确定选择磁盘是否继续服务于上述的三个ring；步骤7、继续添加磁盘，如果当前已有角色都部署完毕后，还存在有空闲的磁盘，将其纳入到已有的角色中；步骤8、磁盘转换用途。进一步地，所述步骤5中在踢盘缩容时罗列出块存储实际占用的磁盘。进一步地，所述步骤6在踢盘缩容时需要罗列出对象存储实际占用的磁盘。进一步地，所述步骤7在操作继续添加磁盘时，首先选择服务角色，然后选择磁盘，步骤主要有两步：1、对选中磁盘进行mkfs操作；2、将初始化完毕的磁盘落库。进一步地，所述步骤8磁盘转换用途具体步骤为：1、将待转换磁盘从原存储集群踢盘，磁盘status变成为init状态；2、在磁盘管理界面选择初始化磁盘操作，点击过后出现选择项，选择对象存储、块存储中的一项，完成格式化，给所有的存储角色提供服务。进一步地，所述步骤1的部署服务，开始部署工作，具体为：nova-api将部署请求发送至tuscloudos-api，tuscloudos-api执行deploy操作时，完成fabric的一些任务，包括：初始化节点，配置ntp，计算节点启动nova-compute，对象存储storage节点启动object-store的相关服务。本发明的有益效果是：本发明管理员在节点部署管理添加节点信息。安装完操作系统后，选择角色进行部署工作。首先选择网络信息，包括计算节点的数据网络和存储网络，也还有对象存储节点的对象存储proxy网络、对象存储storage网络以及对象存储replication网络。选定网络信息后，选择存储磁盘，完成部署工作，可以满足全面使用块存储、对象存储功能。以下将结合附图对本发明的构思、具体结构及产生的技术效果作进一步说明，以充分地了解本发明的目的、特征和效果。附图说明图1是本发明的流程图。具体实施方式如图1所示，本发明提供了一种云节点混合部署方法，包括以下步骤：步骤1、节点部署，选取目标节点，首先配置网络信息，为目标节点选择网络类型和网卡信息；发现磁盘操作，在部署节点之前先发现磁盘，用户进行磁盘初始化的操作和选择对象存储；部署服务，开始部署工作；磁盘特征标记，部署节点时磁盘信息带有部署节点角色的特征；后续添加磁盘，节点部署如果有剩余的空闲磁盘，之后在节点部署处选择添加磁盘给某种角色；步骤2、发现磁盘环节，先执行发现磁盘操作，接下来再根据用途进行有针对性的磁盘格式化操作；步骤3、块存储集群扩容，从所有节点上选择purpose为block_device的若干磁盘，完成扩容，更新novastorage_disks表的disk状态；步骤4、对象存储集群扩容，从所有节点上选择purpose为object_store的若干磁盘，完成扩容，更新novastorage_disks表的disk状态和tuscloudos中object_store_disks表的状态；步骤5、块存储踢盘缩容，对tusdfs进程的操作，确定选择磁盘是否继续服务于所属的集群；步骤6、对象存储踢盘缩容，对accountring，objectring以及containerring的操作，确定选择磁盘是否继续服务于上述的三个ring；步骤7、继续添加磁盘，如果当前已有角色都部署完毕后，还存在有空闲的磁盘，将其纳入到已有的角色中；步骤8、磁盘转换用途。具体内容如下：一、概要设计管理员在节点部署管理添加节点信息。安装完操作系统后，选择角色进行部署工作。首先选择网络信息，包括计算节点的数据网络和存储网络，也还有对象存储节点的对象存储proxy网络、对象存储storage网络以及对象存储replication网络。选定网络信息后，选择存储磁盘，完成部署工作。二、详细设计1、权限角色权限admin部署卸载节点，集群扩容缩容。owner使用创建好的块存储集群和对象存储集群。member使用创建好的块存储集群和对象存储集群。2、节点部署1)选取目标节点。首先配置网络信息。为目标节点选择网络类型和网卡信息。2)发现磁盘操作。在部署节点之前需要先发现磁盘。发现磁盘过后，当前机器可用磁盘都会显示出来。这些磁盘没有挂载点，没有文件系统，也没有用途的标记，完全是操作系统刚装备完成后的裸设备。接下来需要用户进行磁盘初始化的操作，比如块存储，那么mkfs成ext4的文件系统，并挂载磁盘到/sd*这样的目录；选择对象存储，那么mkfs成xfs的文件系统，并挂载磁盘到/srv/node/sd*这样的目录。3)部署服务。开始部署工作，依旧是nova-api将部署请求发送至tuscloudos-api，tuscloudos-api执行deploy操作时，主要是完成fabric的一些任务，诸如初始化节点，配置ntp，启动相关服务进程(计算节点启动nova-compute，对象存储storage节点启动object-store的相关服务)。这两方面的任务先执行fabric的任务，确保服务首先启动正常(做完之后要准备回调nova服务更新physical_hosts的节点状态)。4)磁盘特征标记。部署节点时磁盘信息带有部署节点角色的特征。以部署计算节点为例，当部署完成后，所选择的磁盘带有block_device的purpose信息；对象存储的话，磁盘带有object_store的purpose信息。保证不同节点在使用磁盘时不会发生冲突。磁盘用途特征目前有block_device(块存储)、local(本地存储)、third_party(第三方存储)以及object_store(对象存储)等。5)后续添加磁盘。节点部署如果有剩余的空闲磁盘，之后还可以在节点部署处选择添加磁盘给某种角色。在节点部署添加操作添加磁盘，选择角色，将该磁盘按照选定角色的要求进行mkfs和挂载等一系列操作。6)磁盘转换用途。在用户需要把磁盘转换使用用途的场景下，提供这样的能力。比如，用户的块存储需要扩容，磁盘需要从对象存储抽取。这时当完成对应集群踢盘缩容操作后，进行磁盘初始化操作(即磁盘数据全部清除，同时mkfs，这个需要用户选择，接下来的用途是块存储，还是对象存储，mkfs成相应的样子)。3、发现磁盘环节目前，发现磁盘环节的现状是块存储和对象存储各自操作自己组建的数据库表，没有考虑混合部署共享机器。块存储操作nova的storage_disks表，将所有磁盘的初始用途标记成block_device；对象存储操作tuscloudos的object_store_disk表，并没有设定磁盘用途。两张表的字段差别较大。两种规划：1)、将nova的storage_disk表抽离出来，放置到tuscloudos组件中。这样做的考虑是，磁盘和机器都是基础资源信息，放置到其他位置更合理一些。nova组件应该只关注计算节点和资源池这些操作对象本身。发现磁盘过去是把初始化好的磁盘信息落库，现在部署节点过程已经完成落库，已经没有必要再保留发现磁盘操作了。而且nova和object_store都有发现磁盘操作，共享同一个节点会出现一定的问题。2)、nova的storage_disk表仍旧保留，这样的好处是对现有流程的侵入性比较小。目前平台中访问disk接口的地方较多，如果移入tuscloudos-api，统统都要修改。保留的话，只需要object_store角色部署时，也来更新这张表，标明用途就可以避免冲突。发现磁盘环节会把当前机器的裸设备全部落库，这与过去不同的是：过去是在完成磁盘格式化以后，把带有文件系统的磁盘落库；现在是先执行发现磁盘操作，接下来再根据用途进行有针对性的磁盘格式化操作。4、块存储集群扩容块存储集群扩容流程基本与过去一致，扩容可以操作的是is_compute角色为true的节点。从所有节点上选择purpose为block_device的若干磁盘，完成扩容，更新novastorage_disks表的disk状态。5、对象存储集群扩容对象存储集群扩容流程基本与过去一致，扩容可以操作的是is_object_storage角色为true的节点。从所有节点上选择purpose为object_store的若干磁盘，完成扩容，更新novastorage_disks表的disk状态和tuscloudos中object_store_disks表的状态。6、块存储踢盘缩容块存储踢盘，实际上是对tusdfs进程的操作，确定选择磁盘是否继续服务于所属的集群。在踢盘缩容时需要罗列出块存储实际占用的磁盘，以避免对其他角色磁盘的操作。7、对象存储踢盘缩容对象存储踢盘，实际上是对accountring，objectring以及containerring的操作，确定选择磁盘是否继续服务于上述的三个ring。在踢盘缩容时需要罗列出对象存储实际占用的磁盘，以避免对其他角色磁盘的操作。8、继续添加磁盘在部署节点环节，存在剩余磁盘的可能。如果当前已有角色都部署完毕后，还存在有空闲的磁盘，可以考虑将其纳入到已有的角色中。在操作继续添加磁盘时，首先选择服务角色，然后选择磁盘。步骤主要有两步：1)对选中磁盘进行mkfs操作；2)将初始化完毕的磁盘落库；9、磁盘转换用途(是否支持)具体步骤：1)将待转换磁盘从原存储集群踢盘，磁盘status变成为init状态；2)在磁盘管理界面选择初始化磁盘操作，点击过后出现选择项，选择对象存储、块存储中的一项，完成格式化。可以给所有的存储角色提供服务。10、注意点1)并发部署问题如果两个终端同时操作一台节点，进行部署操作。要首先判断节点状态，如果是deploying状态，则退出等待。直到节点状态恢复为其他可部署状态。2)对已有流程和数据表的调整storage_disks从nova组件抽离出来以后，所有涉及读取磁盘信息的流程都要做调整。所有针对磁盘的初始化、更新、踢盘操作等等都要做调整。三.详细用例1、管理员部署计算节点。填写必要的节点信息，完成节点初始化后。勾选计算节点角色进行部署，部署过程会将该节点除系统盘以外的其他所有盘都mkfs。需要考虑部署节点时选择部分磁盘进行操作，如果该节点是安装好操作系统阶段，可以整机部署。2、管理员部署对象存储proxy节点。proxy节点部署只影响管理网络，可以与其他角色共存，不需要特殊考虑。3、管理员部署对象存储storage节点。部署过程会将该节点除系统盘以外的其他所有盘都mkfs，这将影响已经部署的计算节点块存储数据的安全性。需要考虑部署节点时选择部分磁盘进行操作，如果该节点是安装好操作系统阶段，可以整机部署。4、同时部署计算节点和对象存储节点角色，考虑到磁盘使用的复杂性，考虑不支持该操作。5、管理员卸载计算节点。卸载计算节点不涉及磁盘操作，目前考虑应该无碍。6、管理员卸载对象存储proxy和storage节点，卸载不涉及磁盘操作，目前考虑应该无碍。7、块存储集群扩容，选择计算节点上的磁盘，purpose用途为block_device的。8、对象存储集群扩容，是选择不同对象存储节点上的磁盘，加入zone。在混合部署的场景下，这些磁盘也是计算节点的磁盘，要考虑purpose用途设置为object_store，避免和块存储使用冲突。9、对象存储集群踢盘和加盘，操作的是ring的使用状态in和out。踢盘和加盘要注意，不能操作块存储使用的磁盘。10、要考虑节点部署的并发问题，如果该节点是deploying状态，那么其他任何对该节点的部署请求都拒绝掉。以上详细描述了本发明的较佳具体实施例。应当理解，本领域的普通技术人员无需创造性劳动就可以根据本发明的构思做出诸多修改和变化。因此，凡本
技术领域：
中技术人员依本发明的构思在现有技术的基础上通过逻辑分析、推理或者有限的实验可以得到的技术方案，皆应在由权利要求书所确定的保护范围内。当前第1页12