CN110768812B - 一种服务器管理系统及方法 - Google Patents

一种服务器管理系统及方法 Download PDF

Info

Publication number
CN110768812B
CN110768812B CN201810830402.2A CN201810830402A CN110768812B CN 110768812 B CN110768812 B CN 110768812B CN 201810830402 A CN201810830402 A CN 201810830402A CN 110768812 B CN110768812 B CN 110768812B
Authority
CN
China
Prior art keywords
node
server
management instruction
management
forwarding
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201810830402.2A
Other languages
English (en)
Other versions
CN110768812A (zh
Inventor
林益帆
苗辉
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Guizhou Baishancloud Technology Co Ltd
Original Assignee
Guizhou Baishancloud Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Guizhou Baishancloud Technology Co Ltd filed Critical Guizhou Baishancloud Technology Co Ltd
Priority to CN201810830402.2A priority Critical patent/CN110768812B/zh
Publication of CN110768812A publication Critical patent/CN110768812A/zh
Application granted granted Critical
Publication of CN110768812B publication Critical patent/CN110768812B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/04Network management architectures or arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0803Configuration setting

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)

Abstract

本发明公开了一种服务器管理系统及方法。所公开的系统包括:中心节点,用于下发管理指令,接收执行结果;第一服务器节点,用于接收转发的第一管理指令、执行第一管理指令、返回第一管理指令的第一执行结果,用于接收转发的第二管理指令、转发第二管理指令,还用于接收第二管理指令的第二执行结果、转发第二执行结果;以及第二服务器节点,用于接收第一服务器节点转发的第二管理指令、执行第二管理指令、向第一服务器节点返回第二执行结果,其中,从具有转发第二管理指令和第二执行结果的能力的至少两个第一服务器节点中确定一个第一服务器节点作为转发节点。所公开的方案可以配置多条路径到达同一被管理节点,执行时选择最优路径。

Description

一种服务器管理系统及方法
技术领域
本发明涉及计算机网络技术领域,尤其涉及一种服务器管理系统及方法。
背景技术
随着计算机网络规模的不断扩大,在一个网络中可能同时存在几万台甚至是几十万台服务器的情况。如何高效地管理这些海量服务器,例如,批量地执行指令、进行配置变更、获取指令执行结果,一直是人们研究的热点。
在现有技术中,通常采用saltstack、ansible等开源的自动化运维软件(或称为服务器集中化管理软件)、或者使用haproxy、nginx等代理软件进行二次开发来实现海量服务器的管理。在网络中的服务器数量较少的情况下(例如,几百台至几千台),这种方法基本上能够满足对服务器进行管理的要求。
然而,在面对服务器数量巨大(几万台甚至是几十万台)、网络状况复杂、高频率高并发使用等特殊情况时,使用这些开源软件不能实现对海量服务器进行有效管理的要求。
下面以使用saltstack进行服务器管理的现有技术方案为例来说明现有技术方案的主要缺点。
图1示出了使用saltstack进行服务器管理的现有技术方案的示意图。如图1所示,该技术方案采用了3层节点,第一层是master(即,中心节点),第二层是syndic(即,代理节点),第三层是minion(即,被管理的服务器节点)。中心节点通过代理节点来间接地管理服务器节点。这种技术方案主要存在以下缺点:
(1)无法应对复杂的网络环境和变化。
例如,由于中心节点和其他被管理机器之间的网络不一定是连通的,所以需要引入代理节点,saltstack使用syndic作为代理节点来进行信息转发,在代理节点故障或网络变差时,要新增和变更代理节点需要很复杂的操作(例如,包括选择机器、安装软件、修改配置等具体步骤);而且,在选择备用机器之前无法预先判断其进行信息转发的最终质量,只能在运行后才知道所选择的备用机器是否适于作为代理节点,不适合作为代理节点的话则需要重新选择机器。
(2)无法同时运行多个任务。
例如,在对数以万计的机器同时进行管理操作时,会耗尽中心节点的所有资源,成功率也会很低,结果的回收也可能会把内存耗尽。在多个任务同时执行的情况下情况更加严重,而且单机的socket数量也不够分配。
(3)实时性差。
例如,由于现有技术采用的编程语言(例如,采用了解释型的python语言,运行效率较低)和并发模型(进程或线程,创建和切换成本高昂)的限制,对数万台机器同时执行管理指令时,一般都需要数十分钟的执行时间,而且还可能有部分机器会丢失反馈数据,导致数据收集结果不准确。无法满足对实时性和可靠性要求较高的场景下的应用。
(4)saltstack等代理软件的安装管理很不方便。
(5)代理节点上使用的代理软件的状态不正常(例如,代理软件挂掉)会影响代理节点本身的功能。
(6)代理软件需要占用额外的端口,对于服务器开放端口有限制的场景会有影响。
(7)代理软件本身需要配置和安全控制,增删机器都需要对配置进行修改,维护成本高。
(8)haproxy、nginx等现有的代理软件不支持对于第七层的HTTP 2.0协议的转发,不适合维护长连接,而且也没办法复用连接。不同的请求需要使用多个连接,由于所支持的旧的HTTP 1.x协议的限制,所有的数据必须按时间顺序,复用同一个连接来进行数据传输,会使接收端无法区分开同时到达的数据。
为了解决上述问题,需要提出新的技术方案。
发明内容
根据本发明的服务器管理系统,包括:
中心节点,中心节点用于下发用于管理不同服务器节点的管理指令,接收管理指令的执行结果;
第一服务器节点,第一服务器节点用于接收来自中心节点或其他第一服务节点转发的第一管理指令、执行第一管理指令、向中心节点或其他第一服务节点返回第一管理指令的第一执行结果,用于接收来自中心节点或其他第一服务节点转发的第二管理指令、转发第二管理指令,还用于接收第二管理指令的第二执行结果、向中心节点或其他第一服务节点转发第二执行结果;以及
第二服务器节点,第二服务节点用于接收第一服务器节点转发的第二管理指令、执行第二管理指令、向第一服务器节点返回第二执行结果,
其中,从具有转发第二管理指令和第二执行结果的能力的至少两个第一服务器节点中确定一个第一服务器节点作为转发节点。
根据本发明的服务器管理系统,其第二服务器节点还用于:
接收来自中心节点的第二管理指令、向其他第二服务器节点转发第二管理指令、接收来自其他第二服务器节点的第二管理指令的第三执行结果、向中心节点或第一服务器节点转发第三执行结果,
其中,第一服务器节点还用于:向中心节点或其他第一服务节点转发第三执行结果。
根据本发明的服务器管理系统,其中心节点、第一服务器节点、及第二服务器节点之间的通信基于HTTP 2.0的长连接模式。
根据本发明的服务器管理系统,基于不同的数据流和/或不同的数据帧来区分基于HTTP 2.0的同一个长连接之上的、中心节点、第一服务器节点、及第二服务器节点之间的不同的管理指令。
根据本发明的服务器管理系统,其中心节点还用于:
确定第一服务器节点和第二服务器节点是否作为转发节点。
根据本发明的服务器管理方法,包括:
中心节点执行以下步骤:
下发用于管理不同服务器节点的管理指令,
接收管理指令的执行结果;
第一服务器节点执行以下步骤:
接收来自中心节点或其他第一服务节点转发的第一管理指令、执行第一管理指令、向中心节点或其他第一服务节点返回第一管理指令的第一执行结果,
接收来自中心节点或其他第一服务节点转发的第二管理指令、转发第二管理指令,
接收第二管理指令的第二执行结果、向中心节点或其他第一服务节点转发第二执行结果;以及
第二服务器节点执行以下步骤:
接收第一服务器节点转发的第二管理指令、执行第二管理指令、向第一服务器节点返回第二执行结果。
根据本发明的服务器管理方法,其中心节点还执行以下步骤:
从具有转发第二管理指令和第二执行结果的能力的至少两个第一服务器节点中确定一个第一服务器节点作为转发节点。
根据本发明的服务器管理方法,其第二服务器节点还执行以下步骤:
接收来自中心节点的第二管理指令、向其他第二服务器节点转发第二管理指令、接收来自其他第二服务器节点的第二管理指令的第三执行结果、向中心节点或第一服务器节点转发第三执行结果;
第一服务器节点还执行以下步骤:
向中心节点或其他第一服务节点转发第三执行结果。
根据本发明的服务器管理方法,其中心节点、第一服务器节点、及第二服务器节点之间的通信基于HTTP 2.0的长连接模式。
根据本发明的服务器管理方法,基于不同的数据流和/或不同的数据帧来区分基于HTTP 2.0的同一个长连接之上的、中心节点、第一服务器节点、及第二服务器节点之间的不同的管理指令。
根据本发明的上述技术方案,可以配置多条路径到达同一被管理节点,执行时选择最优路径。
附图说明
并入到说明书中并且构成说明书的一部分的附图示出了本发明的实施例,并且与相关的文字描述一起用于解释本发明的原理。在这些附图中,类似的附图标记用于表示类似的要素。下面描述中的附图是本发明的一些实施例,而不是全部实施例。对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,可以根据这些附图获得其他的附图。
图1示出了使用saltstack进行服务器管理的现有技术方案的示意图。
图2示例性地示出了根据本发明的服务器管理系统的示意图。
图3(a)-3(c)示例性地示出了根据本发明的服务器管理方法的示意流程图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明的一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互任意组合。
图2示例性地示出了根据本发明的服务器管理系统的示意图。
如图2所示,根据本发明的服务器管理系统,包括:
中心节点(即,图2中的server(master)),中心节点用于下发用于管理不同服务器节点的管理指令,接收管理指令的执行结果;
第一服务器节点(即,图2中的agent-a(转发)、agent-b(转发)、agent-f(转发)),第一服务器节点用于接收来自中心节点或其他第一服务节点转发的第一管理指令、执行第一管理指令、向中心节点或其他第一服务节点返回第一管理指令的第一执行结果,用于接收来自中心节点或其他第一服务节点转发的第二管理指令、转发第二管理指令,还用于接收第二管理指令的第二执行结果、向中心节点或其他第一服务节点转发第二执行结果;以及
第二服务器节点(即,图2中的agent-c、agent-d、agent-e、agent-h),第二服务节点用于接收第一服务器节点转发的第二管理指令、执行第二管理指令、向第一服务器节点返回第二执行结果,
其中,从具有转发第二管理指令和第二执行结果的能力的至少两个第一服务器节点中确定一个第一服务器节点作为转发节点(即,图2中的“到同agent有多种路径”)。
可选地,第二服务器节点(即,图2中的agent-g),还用于:
接收来自中心节点的第二管理指令、向其他第二服务器节点转发第二管理指令、接收来自其他第二服务器节点的第二管理指令的第三执行结果、向中心节点或第一服务器节点转发第三执行结果,
其中,第一服务器节点还用于:
向中心节点或其他第一服务节点转发第三执行结果。
可选地,中心节点、第一服务器节点、及第二服务器节点之间的通信基于HTTP 2.0的长连接模式(即,图2中的“长连接”)。
可选地,基于不同的数据流和/或不同的数据帧来区分基于HTTP 2.0的同一个长连接之上的、中心节点、第一服务器节点、及第二服务器节点之间的不同的管理指令。
可选地,中心节点还用于:
确定第一服务器节点和第二服务器节点是否作为转发节点(即,图2中的“中心策略决定直连或转发”)。
例如,server节点(即,上述中心节点)可以安装服务端(server)模块,多个agent节点(包括第一服务器节点和第二服务器节点)可以安装客户端(agent)模块。
server节点可以用于:(1)接受指令(例如,管理指令)任务(2)管理调度指令的传输方式(3)收集agent的执行结果(4)提供接口用于提交查询任务状态。
agent节点可以用于:(1)接受本机要的指令执行并返回结果(2)接受转发指令并发送到目标机并收集结果。
例如,server节点与agent节点之间、agent节点与agent节点之间可以建立HTTP2.0连接,并把连接维护起来(长连接)并保持心跳,利用HTTP 2.0多路复用的特性,可以在上面并行地执行不同的任务指令。
例如,还可以利用HTTP 2.0的TLS加密来保证数据传输的可靠性和安全性。
例如,server节点中的服务端模块与agent节点中的客户端模块可以使用go语言开发。与使用基于python语言开发的saltstack技术的现有技术方案相比,减小了处理时延,提高了实时性。
例如,可以使用协程替换现有技术的进程和/或线程作为并发模型。与使用进程和/或线程的现有技术方案相比,能够使普通服务器同时运行数十万协程进行并发的指令下发操作,进一步减小了处理时延,进一步提高了实时性。
例如,还可以基于HTTP 2.0协议以二进制数据帧和/或数据流为单位进行数据传输,即,可以基于数据帧和/或数据流对数据进行标识(即,复用)。
例如,还可以在同一条HTTP2.0长连接上,同时下发不同的指令,通过数据帧和/或数据流来区分不同指令(例如,管理指令)及不同指令各自对应的执行结果。
例如,图2中显示了在复杂网络中进行数据(包括上述管理指令)传输的几种情况:
1、agent-a、agent-b、agent-g表示与server节点直接连通的节点,agent-a、agent-b、agent-g与server节点之间能够进行直接数据传输。
2、agent-c、agent-d、agent-e、agent-f表示与server节点无法直接连通、但是与agent-a或agent-b直接连通的节点,agent-c、agent-d、agent-e、agent-f的任务(即,对其进行管理的指令)可以通过agent-a或agent-b转发。即,agent-c、agent-d、agent-e、agent-f与server节点之间能够通过agent-a或agent-b的一次转发进行间接数据传输。
3、agent-h表示与server节点、agent-a、agent-b都无法直接连通、与agent-f直接连通的节点,agent-h的任务(即,对其进行管理的指令)需要先经过agent-b再经过agent-f转发。即,agent-h与server节点之间能够通过agent-b和agent-f的两次转发进行间接数据传输。
本发明的上述技术方案相对于现有技术方案(例如,使用saltstack、ansible、haproxy、nginx等进行服务器管理的方案)具有以下优点:
1、在现有技术方案中,例如,当agent-b节点出现问题时,也会使agent-d的任务无法执行,导致其任务失败。这是因为现有技术中的代理节点(例如,agent-b节点)与被管理节点(例如,agent-d节点)之间是一对多的关系。当代理节点出现问题时,如果不重新挑选代理节点、并且进行重新配置,那么该代理节点负责代理的机器(即,被管理节点)所需要执行的任务都会失败。
然而,根据本发明的上述技术方案中的代理节点与被管理节点之间是多对多的关系。如果agent-b节点出现问题时,server节点要对agent-d节点下发指令时,server节点的策略是先尝试由agent-b节点转发,当发现与agent-b节点之间的连接状态不正常时,再尝试由agent-a节点转发,如果检测到与agent-a节点之间的连接状态正常时,则通过agent-a节点正常执行转发,从而将任务成功转发至agent-d节点。
2、在现有技术方案中,例如,当agent-a节点出现问题时,会使agent-c节点的任务无法执行,导致任务失败。因此,此时需要更换代理节点。如果想把agent-g节点设置成新的代理节点来对agent-c节点下发指令,则需要在agent-g节点(机器)上安装现有技术的上述代理软件,并对agent-g节点进行配置,使agent-g节点对agent-c节点的数据转发操作。而且,在安装完代理软件之后,还需要测试agent-g节点与master节点之间以及与agent-c节点之间的连通性,如果最终得到的测试结果说明它们之间不连通或者连通性差,则需要重复上面的操作步骤直到人工挑选到合适的代理节点为止,耗时长、人工成本高。
然而,根据本发明的上述技术方案,由于每个节点都能转发,master节点会定时(自动)地对机器(节点)进行扫描,保证每台机器都有两台以上或三台以上的机器与其连通,在agent-a节点出现问题的时候,由于事先预知了agent-g节点是与agent-c节点连通的,所以可以直接自动修改策略让agent-c节点的任务由agent-g节点转发(如图2中的虚线箭头所示)。
可以设置以固定时间间隔(例如,5分钟)对所有机器发起测试请求,测试请求中包含测试路径、测试机器、数据传输时间、测试路径的持续使用时长。数据传输时间越短且路径持续使用时长越长,则代表转发效果越好,就可以优先使用该路径上的转发机器来进行数据转发。以单台机器为例,对其他节点到该机器的数据传输时间的倒数值和路径连接时长值进行加权求和,并对最终的求和结果按照数值大小进行排序,便能得到与转发效果由好到坏的顺序对应一致的排序结果,使用时按照排序结果选择节点就能够获得最优路径。
3、在现有技术方案中,例如,当需要对数万台机器进行指令下发,并同时下发多个指令任务时,使用saltstack无法完成这种操作;而使用基于haproxy、nginx、HTTP 1.x协议的方案来转发指令时,每次都需要重新建立连接,master节点需要建立的连接数为机器数量乘上指令任务数,此时会迅速耗光机器的socket数量,导致服务不可用。建立连接需要花费成本。而且,由于不知道网络的链路状态,通常都需要设定一个建连超时阈值,在未超过该超时阈值时,其他任务都会被阻塞,导致了实时性较差。并发模型使用进程,导致进程间调度的开销大,也无法同时并行运行太多指令。
然而,根据本发明的上述技术方案,所使用的数据传输通道都是HTTP 2.0长连接,如果agent-a节点下挂有一万台机器,中心节点对这一万台下发是复用中心节点与agent-a节点之间的同一个HTTP 2.0长连接,中心节点只需要建立自身与转发节点及自身与直连节点之间的HTTP 2.0长连接,不同任务可以复用同一个HTTP 2.0长连接。而且,master(即,中心节点)会维护HTTP 2.0长连接的状态,当要使用该连接时直接判断连接状态,当要下发指令时不需要等待建连。例如,可以在中心节点配置动态策略,来指定指令的传输方式,通过变更动态策略就能够变更代理节点和传输路径。可以配置到达同一机器的多条路径,执行数据传输的时候选择最优路径。
图3(a)-3(c)示例性地示出了根据本发明的服务器管理方法的示意流程图。
根据本发明的服务器管理方法,包括:
如图3(a)的实线框所示,中心节点执行以下步骤:
步骤C302:下发用于管理不同服务器节点的管理指令,
步骤C304:接收管理指令的执行结果;
如图3(b)的实线框所示,第一服务器节点执行以下步骤:
步骤F302:接收来自中心节点或其他第一服务节点转发的第一管理指令、执行第一管理指令、向中心节点或其他第一服务节点返回第一管理指令的第一执行结果,
步骤F304:接收来自中心节点或其他第一服务节点转发的第二管理指令、转发第二管理指令,
步骤F306:接收第二管理指令的第二执行结果、向中心节点或其他第一服务节点转发第二执行结果;以及
如图3(c)的实线框所示,第二服务器节点执行以下步骤:
步骤S302:接收第一服务器节点转发的第二管理指令、执行第二管理指令、向第一服务器节点返回第二执行结果。
可选地,如图3(a)的虚线框所示,中心节点还执行以下步骤:
步骤C306:从具有转发第二管理指令和第二执行结果的能力的至少两个第一服务器节点中确定一个第一服务器节点作为转发节点。
可选地,如图3(c)的虚线框所示,第二服务器节点还执行以下步骤:
步骤S304:接收来自中心节点的第二管理指令、向其他第二服务器节点转发第二管理指令、接收来自其他第二服务器节点的第二管理指令的第三执行结果、向中心节点或第一服务器节点转发第三执行结果;
如图3(b)的虚线框所示,第一服务器节点还执行以下步骤:
步骤F308:向中心节点或其他第一服务节点转发第三执行结果。
可选地,中心节点、第一服务器节点、及第二服务器节点之间的通信基于HTTP 2.0的长连接模式。
可选地,基于不同的数据流和/或不同的数据帧来区分基于HTTP 2.0的同一个长连接之上的、中心节点、第一服务器节点、及第二服务器节点之间的不同的管理指令。
可选地,如图3(a)的虚线框所示,中心节点还执行以下步骤:
步骤C308:确定第一服务器节点和第二服务器节点是否作为转发节点。
为了使本领域技术人员更清楚地了解根据本发明的上述服务器管理方法,下面将结合一个具体实施例进行描述。该实施例可以包括以下步骤:
1、agent节点实现指令调用的rpc(远程过程调用,它是一种通过网络从远程计算机程序上请求服务,),用于接受来自中心节点或转发节点指令并执行。
2、agent节点使用自定义协议实现转发指令的rpc。
例如,可以使用以下示例性的自定义协议:
a)如要直接给图中的agent-g节点下发指令则以(agent-g+指令内容)的形式直接发给agent-g节点,返回结果。
b)如果要给图中agent-h节点发指令则,生成(agent-b-agent-f-agent-h+指令内容)发给agent-b机器(节点),agent-b机器收到指令发现是转发指令则生成(agent-f-agent-h+指令内容)发给agent-f机器,agent-f机器则以(agent-h+指令内容)发给agent-h机器,然后依次返回结果。
3、实现HTTP 2.0的长连接池。
a)为了方便判断状态,把HTTP 2.0连接的状态包括:“ready:正常可以使用”、“idle:连接中或瞬时失败”、“shutdown:连接断开或关闭三种”。
b)在内存中缓存每个用到的HTTP 2.0的连接。
c)开启一个独立的线程,使用lru策略实时地对每个HTTP 2.0的连接状态进行扫描。如果是ready,则直接使用;如果是idle,则把连接标记为失效,但是不删除连接;如果在设定的超时时间之内状态恢复为ready,则把连接标记为正常;如果达到超时时间,或主动关闭连接则把连接标记为shutdown,剔除该连接。
4、在调用agent节点的rpc时,从本机连接池中查询是否已经存在需要的连接,没有则创建连接,并保持心跳用于修改连接状态;如果有则判断连接状态,连接状态正常(ready)则直接使用。
5、server节点利用agent节点的转发rpc对管理的所有机器(节点)进行扫描测试,检测机器之间的联通性,生成指令下发的策略,用于下发时使用。
6、server节点定时对agent节点扫描并调整策略。
7、server节点提供封装好的接口,外部可以提交下发指令任务并指定机器列表、并发数、超时时间等到server节点,由server节点根据策略下发指令到各个目标机器并收集结果。
8、server节点提供任务状态查询的接口用于查询任务状态。
根据本发明的上述技术方案,具有以下优点:
1、可以配置多条路径到达同一被管理节点,执行时选择最优路径。
2、除了中心节点之外的所有节点都可以作为转发节点,新增和修改代理节点快捷。
3、可以在中心节点配置通用策略来制定指令的传输方式,通过修改策略就能变更代理节点和传输路径。
4、sever节点与agent节点之间、或者agent节点与agent节点之间可以保持长连接,不用花费建立连接的开销。不同指令可以复用长连接,提高了性能,使用少量的socket就能执行大量的指令传输。可以保持心跳,在网络抖动或agent节点故障时能及时调整策略。
5、可以并行地执行针对数十万指令的下发、执行、及执行结果接收操作,上述操作的延迟远远小于现有技术,几乎是实时的。
上面描述的内容可以单独地或者以各种方式组合起来实施,而这些变型方式都在本发明的保护范围之内。
本领域普通技术人员可以理解,上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中,在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分;例如,一个物理组件可以具有多个功能,或者一个功能或步骤可以由若干物理组件合作执行。某些组件或所有组件可以被实施为由处理器,如数字信号处理器或微处理器执行的软件,或者被实施为硬件,或者被实施为集成电路,如专用集成电路。这样的软件可以分布在计算机可读介质上,计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的,术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外,本领域普通技术人员公知的是,通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据,并且可包括任何信息递送介质。
最后应说明的是:以上实施例仅用以说明本发明的技术方案,而非对其限制。尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例的技术方案的精神和范围。

Claims (9)

1.一种服务器管理系统,其特征在于,包括:
中心节点,所述中心节点用于下发用于管理不同服务器节点的管理指令,接收所述管理指令的执行结果;发起测试请求,确定中心节点到每一服务器节点的至少两条连接路径,并按转发效果对所述至少两条连接路径进行排序,选择最优路径上的节点作为转发节点;
第一服务器节点,所述第一服务器节点用于接收来自所述中心节点或其他第一服务器节点转发的第一管理指令、执行所述第一管理指令、向所述中心节点或所述其他第一服务器节点返回所述第一管理指令的第一执行结果,用于接收来自所述中心节点或其他第一服务器节点转发的第二管理指令、转发所述第二管理指令,还用于接收所述第二管理指令的第二执行结果、向所述中心节点或其他第一服务器节点转发所述第二执行结果;以及
第二服务器节点,所述第二服务器节点用于接收所述第一服务器节点转发的所述第二管理指令、执行所述第二管理指令、向所述第一服务器节点返回所述第二执行结果。
2.如权利要求1所述的服务器管理系统,其特征在于,所述第二服务器节点还用于:
接收来自所述中心节点的所述第二管理指令、向其他第二服务器节点转发所述第二管理指令、接收来自所述其他第二服务器节点的第二管理指令的第三执行结果、向所述中心节点或所述第一服务器节点转发所述第三执行结果,
其中,所述第一服务器节点还用于:向所述中心节点或其他第一服务器节点转发所述第三执行结果。
3.如权利要求1或2所述的服务器管理系统,其特征在于,所述中心节点、所述第一服务器节点、及所述第二服务器节点之间的通信基于HTTP 2.0的长连接模式。
4.如权利要求3所述的服务器管理系统,其特征在于,基于不同的数据流和/或不同的数据帧来区分基于HTTP 2.0的同一个长连接之上的、所述中心节点、所述第一服务器节点、及所述第二服务器节点之间的不同的管理指令。
5.如权利要求2所述的服务器管理系统,其特征在于,所述中心节点还用于:
确定所述第一服务器节点和所述第二服务器节点是否作为转发节点。
6.一种服务器管理方法,其特征在于,包括:
中心节点执行以下步骤:
下发用于管理不同服务器节点的管理指令,
接收所述管理指令的执行结果;
发起测试请求,确定中心节点到每一服务器节点的至少两条连接路径,并按转发效果对所述至少两条连接路径进行排序,选择最优路径上的节点作为转发节点;
第一服务器节点执行以下步骤:
接收来自所述中心节点或其他第一服务器节点转发的第一管理指令、执行所述第一管理指令、向所述中心节点或所述其他第一服务器节点返回所述第一管理指令的第一执行结果,
接收来自所述中心节点或其他第一服务器节点转发的第二管理指令、转发所述第二管理指令,
接收所述第二管理指令的第二执行结果、向所述中心节点或其他第一服务器节点转发所述第二执行结果;以及
第二服务器节点执行以下步骤:
接收所述第一服务器节点转发的所述第二管理指令、执行所述第二管理指令、向所述第一服务器节点返回所述第二执行结果。
7.如权利要求6所述的服务器管理方法,其特征在于,所述第二服务器节点还执行以下步骤:
接收来自所述中心节点的所述第二管理指令、向其他第二服务器节点转发所述第二管理指令、接收来自所述其他第二服务器节点的第二管理指令的第三执行结果、向所述中心节点或所述第一服务器节点转发所述第三执行结果;
所述第一服务器节点还执行以下步骤:
向所述中心节点或其他第一服务器节点转发所述第三执行结果。
8.如权利要求7所述的服务器管理方法,其特征在于,所述中心节点、所述第一服务器节点、及所述第二服务器节点之间的通信基于HTTP 2.0的长连接模式。
9.如权利要求8所述的服务器管理方法,其特征在于,基于不同的数据流和/或不同的数据帧来区分基于HTTP 2.0的同一个长连接之上的、所述中心节点、所述第一服务器节点、及所述第二服务器节点之间的不同的管理指令。
CN201810830402.2A 2018-07-26 2018-07-26 一种服务器管理系统及方法 Active CN110768812B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201810830402.2A CN110768812B (zh) 2018-07-26 2018-07-26 一种服务器管理系统及方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201810830402.2A CN110768812B (zh) 2018-07-26 2018-07-26 一种服务器管理系统及方法

Publications (2)

Publication Number Publication Date
CN110768812A CN110768812A (zh) 2020-02-07
CN110768812B true CN110768812B (zh) 2022-11-08

Family

ID=69327327

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201810830402.2A Active CN110768812B (zh) 2018-07-26 2018-07-26 一种服务器管理系统及方法

Country Status (1)

Country Link
CN (1) CN110768812B (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111343272B (zh) * 2020-02-26 2023-02-07 杭州涂鸦信息技术有限公司 星型网络架构的跨节点请求重试方法和电子设备
CN111327483B (zh) * 2020-03-25 2022-07-12 新华三信息安全技术有限公司 一种设备纳管方法、系统及存储介质
CN114024876B (zh) * 2021-10-15 2023-06-16 中国联合网络通信集团有限公司 一种网络拨测方法、装置、设备及存储介质

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9960964B2 (en) * 2014-02-18 2018-05-01 Cellos Software Ltd System, method and apparatus to manage services in a network
CN106162795B (zh) * 2016-08-31 2018-01-30 邱岩 利用逻辑区域坐标的无线物联网的自我组网和路由方法
CN108206847B (zh) * 2016-12-19 2020-09-04 腾讯科技(深圳)有限公司 Cdn管理系统、方法及装置
CN107493331A (zh) * 2017-08-16 2017-12-19 网宿科技股份有限公司 一种客户端访问方法、服务器及系统
WO2019113786A1 (zh) * 2017-12-12 2019-06-20 深圳前海达闼云端智能科技有限公司 Tfo传输方法、代理服务器和系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
自动化运维工具之Saltstack;SoulMio;《https://blog.51cto.com/bovin/1984115》;20171122;全文 *

Also Published As

Publication number Publication date
CN110768812A (zh) 2020-02-07

Similar Documents

Publication Publication Date Title
US7385938B1 (en) Method and apparatus for adjusting a network device configuration change distribution schedule
US20210099335A1 (en) Alarm Method and Apparatus
CN107005426B (zh) 一种虚拟网络功能的生命周期管理方法及装置
WO2017181876A1 (zh) 一种设备状态及资源信息监测方法、相关设备及系统
CN110768812B (zh) 一种服务器管理系统及方法
JP6466003B2 (ja) Vnfフェイルオーバの方法及び装置
CN109960634B (zh) 一种应用程序监控方法、装置及系统
CN105429938B (zh) 一种资源配置方法及装置
CN103200036A (zh) 一种电力系统云计算平台的自动化配置方法
CN108337110A (zh) 一种虚拟资源管理方法及装置、计算机可读存储介质
CN113835844A (zh) 一种容器集群的管理方法、装置及云计算平台
CN112564994B (zh) 流量监测方法、装置、云服务器及存储介质
CN108366087B (zh) 一种基于分布式文件系统的iscsi服务实现方法和装置
EP4164183A1 (en) Default gateway management method, gateway manager, server, and storage medium
CN111478937B (zh) 一种负载均衡方法和装置
CN116886286A (zh) 大数据认证服务自适应方法、装置和设备
CN110011850B (zh) 云计算系统中服务的管理方法和装置
CN113821334A (zh) 一种配置边缘侧设备的方法、装置及系统
CN113824595B (zh) 链路切换控制方法、装置和网关设备
US20230188625A1 (en) Service request handling
US12058001B2 (en) Control device, control method, control program and control system
CN114448941A (zh) 一种网络设备管理方法、装置、电子设备及存储介质
CN110417568B (zh) Nfv策略协商方法及系统
CN111614649B (zh) 关闭tcp短连接的方法及装置
US11627037B2 (en) Management and orchestration of heterogeneous network environment using dynamic, robust and network aware microservices

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant