CN104468283A - 多主机管理系统的监控方法、装置和系统 - Google Patents

Abstract

本发明公开了一种多主机管理系统的监控方法、装置和系统。其中，方法包括：监控主控端与受控端之间的连接状态；将通过监控连接状态所获取的连接状态信息写入到数据库中；受控端从数据库中读取并根据连接状态信息判断主控端与受控端之间是否为不可用的连接状态；根据主控端与受控端之间为不可用连接状态的信息反馈，在受控端信息列表中清除受控端的信息。上述方案使得受控端程序能够及时得知不可用的连接状态，更新配置文件，以重新请求连接，保证主控端和受控端之间的正常通信，提高了多主机管理系统的健壮性。

Description

多主机管理系统的监控方法、装置和系统

技术领域

本发明涉及服务器监控领域，具体涉及一种多主机管理系统的监控方法，主控端服务器，受控端装置及多主机管理系统。

背景技术

网站或网络服务提供者往往需要管理、配置多台服务器，这些服务器可能提供同样的服务，运行同样的程序，并具有相同的配置。当服务器数量众多时，不可能一一登录服务器进行配置。因此，出现了服务器运维工具，如salt-stack工具等。通过这些运维工具，系统运维人员可在一台管理服务器上对多台受控服务器进行远程执行和配置管理，例如，在多台服务器上同时安装、卸载程序，更改配置文件等。

运维工具的使用需要在管理服务器的主控端和各服务器的受控端程序之间配置和建立通信连接，例如，记录对方的IP地址，主机名称，服务端口号等。当由于各种原因导致的配置的通信连接失效时，往往不能及时得知这种变化，而无法做出及时的配置文件的更新或连接请求重启，导致主控端和受控端之间的不可用连接状态一直持续，主控端服务器对受控端机器的远程执行失败。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的一种多主机管理系统的监控方法，主控端服务器，受控端装置及多主机管理系统。

根据本发明的一个方面，提供了一种多主机管理系统的监控方法，包括：

监控主控端与受控端之间的连接状态；

将通过监控连接状态所获取的连接状态信息写入到数据库中，所述连接状态信息供所述受控端从所述数据库中读取并供所述受控端根据所述连接状态信息判断所述主控端与受控端之间是否为不可用连接状态；

根据所述主控端与受控端之间为不可用连接状态的信息反馈，在所述主控端维护的受控端信息列表中清除所述受控端的信息。

根据本发明的另一方面，提供了一种多主机管理系统的监控方法，包括：

从数据库中读取连接状态信息，所述连接状态信息是由主控端通过监控主控端与受控端之间连接状态所获取并写入到数据库中；

根据所述连接状态信息判断主控端与受控端之间是否为不可用连接状态；

若判断出所述主控端与受控端之间为不可用连接状态，对所述不可用连接状态进行信息反馈，并重新启动与主控端之间的连接过程。

根据本发明的另一个方面，提供了一种主控端服务器，包括：

监控模块，适于监控主控端与受控端之间的连接状态；

写入模块，适于将通过监控连接状态所获取的连接状态信息写入到数据库中，所述连接状态信息供所述受控端从所述数据库中读取并供所述受控端根据所述连接状态信息判断所述主控端与受控端之间是否为不可用连接状态；

清除模块，适于根据所述主控端与受控端之间为不可用连接状态的信息反馈，在所述主控端服务器维护的受控端信息列表中清除所述受控端的信息。

根据本发明的另一个方面，提供了一种受控端装置，包括：

读取模块，适于从所述数据库中读取连接状态信息，所述连接状态信息是由主控端通过监控主控端与受控端之间连接状态所获取并写入到数据库中；

判断模块，适于根据所述连接状态信息判断主控端与受控端之间是否为不可用连接状态；

通知模块，适于在判断出所述主控端与受控端之间为不可用连接状态时，对所述不可用连接状态进行信息反馈；

重启模块，适于在判断出所述主控端与受控端之间为不可用连接状态时，重新启动与主控端之间的连接过程。

根据本发明的另一个方面，提供了一种多主机管理系统，包括上述的主控端服务器、受控端装置以及由所述主控端服务器和受控端装置访问的数据库。

根据本发明的多主机管理系统的监控方法及系统，主控端服务器及受控端装置，由主控端程序监控其与各受控端之间的连接状态，并在数据库中写入连接状态信息，受控端程序能够访问该数据库，读取连接状态信息，重新配置。上述的方案中，受控端程序能够及时得知不可用的连接状态，更新配置文件，以重新发其连接，保证主控端和受控端之间的正常通信，使多主机管理系统具有自适应的能力，提高了多主机管理系统的健壮性。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅适于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了根据本发明一个实施例的多主机管理系统的监控方法的流程示意图；

图2示出了根据本发明另一个实施例的多主机管理系统的监控方法的流程示意图；

图3示出了根据本发明一个实施例的多主机管理系统的监控方法的流程示意图；

图4示出了根据本发明另一个实施例的多主机管理系统的监控方法的流程示意图；

图5示出了根据本发明一个实施例的主控端服务器的结构示意图；

图6示出了根据本发明一个实施例的受控端装置的结构示意图；

图7示出了根据本发明一个实施例的多主机管理系统的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

图1示出了根据本发明一个实施例的多主机管理系统的监控方法的流程示意图，如图1所示，该方法包括如下步骤：

步骤S110，监控主控端与受控端之间的连接状态。

常见的多主机管理系统中的运维工具有Puppet，SaltStack等。在这种多主机管理系统中，常以服务器-客户端的模式实现集中配置，即一台服务器上安装有主控端程序，系统管理员通过主控端程序提供的GUI界面，或输入命令行等方式实现对安装有受控端程序的多台服务器的远程命令执行或配置管理。例如，在多台受控端上统一安装、升级或卸载软件，或同时修改多台服务器的密码，以及从主控端向多台受控端复制文件等。

这种管理系统中，要求受控端在主控端的端口上保持连接建立(ESTABLISHED)的状态。通常运维工具提供有主控端上运行的一些连通性测试命令。具体地，主控端指定受控端的信息，例如，受控端的IP地址，调用连通性测试命令，获知主控端与受控端之间的连接状态是否可用。当受控端的ssh服务关闭、或受控端IP发生变化时、配置文件丢失时都可能导致连接状态不可用。

主控端以一定的频率分别对每个管理的受控端进行连通性测试以获取连接状态，例如，30秒执行一次测试命令。还可以通过其他方式监控连接状态，例如，请求应答的方式，将受控端程序配置为在接收到主控端的命令时，返回应答消息。本发明对监控连通状态的具体方式不做限定。

步骤S120，将通过监控连接状态所获取的连接状态信息写入到数据库中。

多主机管理系统只在主控端监控不可用的连接状态，而不为受控端提供检测连接状态的方式。如果出现连接状态不可用的情况，主控端监控到的不可用信息并不能通知到受控端，主控端和受控端之间并没有反馈的机制。而主控端和受控端之间的连接都由作为客户端的受控端发起，因此，当受控端无法得知连接不可用时，不会发起重新配置连接的请求。主控端仍然根据之前的配置信息与受控端通信，这种不可用的连接状态会一直持续，主控端的远程执行命令失败。

本发明提供了一种具有健壮性的多主机管理系统的监控方法，在主控端进行连接状态的监控，但能够及时将连接状态的变化通知给受控端，而使自动重新配置与主控端之间的连接。

具体地，主控端将通过连通性测试等方式获得的连接状态信息写入一个能被受控端读取的数据库中。受控端对该数据库的访问不受主控端与受控端之间连接状态的影响，例如，该数据库可以是一个外网数据库，主控端和受控端通过互联网访问该数据库。受控端从数据库中读取连接状态信息并根据连接状态信息判断主控端与受控端之间是否为不可用的连接状态。

步骤S130，根据主控端与受控端之间为不可用连接状态的信息反馈，在受控端信息列表中清除受控端的信息。

主控端保存并维护有受控端信息列表，用于记录受控端的分组，受控端主机名、IP地址等信息。当受控端读取连接状态信息而得知连接状态不可用时，作为确认信号，通知反馈给主控端，告知主控端受控端已得知连接不可用，并将重启受控端服务，发送连接请求。主控端根据该通知将该受控端的信息从列表中清除。

根据本发明上述实施例提供的多主机管理系统监控方法，由主控端程序监控其与各受控端之间的连接状态，并在数据库中写入连接状态信息，受控端能够访问该数据库，读取连接状态信息并重新配置连接信息。上述的方案中，受控端能够及时得知不可用的连接状态，并及时反馈给主控端以告知主控端清除该受控端的信息，保证主控端和受控端之间的正常通信，提高了多主机管理系统的健壮性。

图2示出了根据本发明另一个实施例的多主机管理系统的监控方法的流程示意图。在该实施例中，以SaltStack中的连接状态监测方法和主控端配置方式为例进行了说明。在SaltStack中，本发明中的主控端程序称为salt-master，受控端程序称为salt-minion。salt-master和salt-minion之间类似于一对多的服务器-客户端的结构。正常状态下，主控端启动后，监听预定的端口，而与该主控端配置了连接的受控端在该端口上一直保持建立(ESTABLISHED)状态。

如图2所示，该方法包括如下步骤：

步骤S210，主控端调用连通性测试命令，判断受控端是否为存活状态，若受控端为非存活状态，执行步骤S220；否则，继续监控。

SaltStack的主控端上提供有test.ping命令，用于检测与受控端之间的连通性。调用该命令时，指定为受控端命名的ID，该ID可以是受控端的主机名。例如，命令的调用方式为salt‘1st-Salt-Minion’test.ping”，其中，1st-Salt-Minion即为受控端ID。若结果显示为“1st-Salt-Minion：True”，表明主控端能够连接到ID为1st-Salt-Minion的受控端，即该受控端为存活状态，否则，判断其为非存活状态。根据配置列表中的各受控端ID，依次调用上述命令。或者使用通配符方式的命令“salt‘*’test.ping”，返回所有受控端的连接状态，其结果显示为“1st-Salt-Minion：true；2nd-Salt-Minion：true”，表明这两个受控端都为存活状态。主控端可以一定的频率调用上述命令，例如，30秒1次。

步骤S220，将非存活状态的受控端的信息写入到数据库中。

具体地，向数据库中写入每次连通性测试命令结果，或写入非存活状态的受控端所在服务器的IP地址、受控端ID等信息，还可以添加时间戳等信息。这些连接状态信息供受控端从数据库中读取并供受控端根据连接状态信息判断主控端与受控端之间是否为不可用连接状态。

步骤S230，接收受控端发送的不可用连接状态的通知，根据通知在受控端信息列表中清除受控端的连接信息。

主控端保存并维护有受控端信息列表，记录连接的各受控端信息，例如，192.168.1.235 SaltMaster，192.168.1.248 1st-Salt-Minion，192.168.1.2442nd-Salt-Minion等。其中，受控端1st-Salt-Minion的IP地址为192.168.1.248。

受控端读取数据库得知不可用状态后，发送不可用连接状态的通知。该通知用于表明受控端已得知不可用连接状态，将要重启服务，建立连接请求。主控端根据这一通知清除相应的受控端信息，准备根据受控端请求在列表中写入新的信息。

步骤S240，接收受控端重启连接服务后发送的第一公钥。

当受控端根据数据库中读取的连接状态信息得知连接状态不可用时，自动通过命令salt-minion start重新启动受控端服务，受控端服务向主控端发送连接请求。

为保证安全性，主控端和受控端需要配置信任关系。在SaltStack中，主控端是依靠openssl证书来与受控端主机认证通信的，该openssl证书在受控端启动后自动生成，包括非对称的公钥证书和私钥证书。受控端保存私钥证书，而将公钥证书发送给主控端供主控端认证，以此保证主控端和受控端之间的连接是授信的。

步骤S250，认证第一公钥并以第一公钥替换保存的第二公钥。

在主控端用salt-key命令来管理公钥证书，例如，“salt-key-a1st-Salt-Minion”命令，认证ID为1st-Salt-Minion的受控端发送的证书，或通过salt-key-A进行批量地自动认证。

第一公钥是受控端服务重启后发送的新生成的公钥，第二公钥是之前保存在主控端用于加密远程执行命令的公钥。认证受控端发送的第一公钥后，自动使用命令“salt-key-d KeyName”将重启之前保存的第二公钥清除。

之后，主控端使用该第一公钥对发送的远程执行命令加密，受控端以第一私钥解密。

步骤S260，根据重新启动的与受控端之间的连接状态，及时更新数据库内写入的连接状态信息。

例如，主控端接收受控端的连接请求并验证公钥证书后，进行一次数据库的写入，将之前写入的不可用状态清除，以避免受控端重复启动服务。

根据本发明上述实施例提供的方法，由主控端监控其与各受控端之间的连接状态，并在数据库中写入连接状态信息，供受控端访问，读取连接状态信息，重新进行连接配置。上述的方案中，受控端能够及时得知不可用的连接状态，并及时反馈给主控端以告知主控端清除该受控端的信息，保证主控端服务器和受控端装置之间的正常通信，提高了多主机管理系统的健壮性。

图3示出了根据本发明一个实施例的多主机管理系统的监控方法的流程示意图，如图3所示，方法包括如下步骤：

步骤S310，从数据库中读取连接状态信息，连接状态信息是由主控端通过监控主控端与受控端之间连接状态所获取并写入到数据库中。

读取主控端每次调用连通性测试命令后写入的结果，或写入的非存活状态的受控端所在服务器的IP地址、受控端ID等信息。例如，主控端调用“salt‘1st-Salt-Minion’test.ping“得到返回结果”1st-Salt-Minion：True“，将该结果写入数据库中，或者主控端只将检测到的非存活状态的受控端ID写入数据库中。

步骤S320，根据连接状态信息判断主控端与受控端之间是否为不可用连接状态。

可选地，判断非存活状态的受控端信息与受控端自身信息是否匹配，若是，则判定主控端与受控端之间为不可用连接状态。例如，主控端将1st-Salt-Minion这一受控端ID写入了数据库，多个受控端从数据库读取该记录并匹配，其中，ID为1st-Salt-Minion的受控端得知了自身的非存活状态。

进一步地，在判断出连接状态不可用后，方法还包括：向主控端发送不可用连接状态的通知，该通知可作为一个确认信号，以告知主控端在受控端信息列表中清除受控端的信息。

步骤S330，若判断出主控端与受控端之间为不可用连接状态，对不可用连接状态进行信息反馈，并重新启动与主控端之间的连接过程。

在受控端自动进行连接的配置，调用service salt-minion start命令重新启动受控端服务。

重新启动与主控端之间的连接过程进一步包括：生成第一公钥和第一私钥；以第一私钥替换受控端保存的第二私钥，并将第一公钥发送给所述主控端，以供所述主控端对所述第一公钥进行认证。

为保证安全性，主控端和受控端需要配置信任关系。在SaltStack中，主控端是依靠openssl证书来与受控端主机认证通讯的，该openssl证书在受控端启动后自动生成，包括非对称的公钥证书和私钥证书。通过证书保证主控端和受控端之间是授信的。受控端将公钥证书发送给主控端。

受控端保存有配置文件，配置文件中记录有受控端ID，主控端IP地址或主机名等信息。具体地，对Saltstack，受控端配置文件保存在/etc/salt/minion目录下，其形式为“master：192.168.1.229，id：1st-Salt-Minion，log_file：/var/log/salt/minion，key_logfile：/var/log/salt/key”等。其中，各字段分别是主控端地址，受控端ID，受控端运行日志的目录，受控端证书认证日志的目录。

在重新启动与主控端之间的连接过程之后，本实施例方法还包括：更新受控端的配置文件。具体地，包括将不可用状态及时间戳写入受控端运行日志中。

图4示出了根据本发明另一个实施例的多主机管理系统的监控方法的流程示意图，如图4所示，方法包括如下步骤：

步骤S410，主控端调用连通性测试命令，判断受控端是否为存活状态，若受控端为非存活状态，执行步骤S420。

例如，在SaltStack工具中，调用test.ping命令检测与受控端之间的连通性。调用该命令时，指定为受控端命名的ID，该ID可以是受控端的主机名。例如，命令的调用方式为salt‘1st-Salt-Minion’test.ping”，其中，1st-Salt-Minion即为受控端ID。若结果显示为“1st-Salt-Minion：True”，表明主控端能够连接到ID为1st-Salt-Minion的受控端，即该受控端为存活状态，否则，判断其为非存活状态。根据配置列表中的各受控端ID，依次调用上述命令。或者使用通配符方式的命令“salt‘*’test.ping”，返回所有受控端的连接状态，其结果显示为“1st-Salt-Minion：true；2nd-Salt-Minion：true”，表明这两个受控端都为存活状态。主控端可以一定的频率调用上述命令，例如，30秒1次

步骤S420，主控端将非存活状态的受控端的信息写入到数据库中。

具体地，向数据库中写入每次连通性测试命令结果，或写入非存活状态的受控端所在服务器的IP地址、受控端ID等信息，还可以添加时间戳等信息。这些连接状态信息供受控端从数据库中读取并供受控端根据连接状态信息判断主控端与受控端之间是否为不可用连接状态。

步骤S430，受控端从数据库中读取非存活状态的受控端的信息。

受控端从数据库中读取主控端每次调用连通性测试命令后写入的结果，或写入的非存活状态的受控端所在服务器的IP地址、受控端ID等信息。

步骤S440，受控端判断非存活状态的受控端信息与受控端自身信息是否匹配，若是，执行步骤S450。

例如，主控端将1st-Salt-Minion这一受控端ID写入了数据库，多个受控端从数据库读取该记录并匹配，其中，ID为1st-Salt-Minion的受控端得知了自身的非存活状态。

步骤S450，受控端向主控端发送不可用连接状态的通知。

受控端读取数据库得知不可用状态后，发送不可用连接状态的通知。该通知用于表明受控端已得知不可用连接状态，将要重启服务，建立连接请求。

步骤S460，主控端根据通知在受控端信息列表中清除受控端的信息。

主控端保存并维护有受控端信息列表，记录连接的各受控端信息，例如，192.168.1.235 SaltMaster，192.168.1.248 1st-Salt-Minion，192.168.1.2442nd-Salt-Minion等。在主控端接收到受控端1st-Salt-Minion发送的不可用连接状态的通知之后，会将相应的受控端的信息“192.168.1.248 1st-Salt-Minion”清除。

步骤S470，受控端重启服务，并生成第一公钥和第一私钥。

步骤S480，受控端以第一私钥替换保存的第二私钥，将第一公钥发送给主控端。

步骤S490，主控端认证并保存第一私钥。

根据本发明上述实施例提供的方法，由主控端监控其与各受控端之间的连接状态，并在数据库中写入连接状态信息，供受控端访问，读取连接状态信息，重新进行连接配置。上述的方案中，受控端能够及时得知不可用的连接状态，并及时反馈给主控端以清除受控端的信息，保证主控端服务器和受控端装置之间的正常通信，提高了多主机管理系统的健壮性。

图5示出了根据本发明一个实施例的主控端服务器的结构示意图，如图5所示，该主控端服务器包括：监控模块510、写入模块520以及清除模块530。

监控模块510，适于监控主控端与受控端之间的连接状态。

主控端保存并维护有受控端信息列表，记录有当前连接的受控端主机名，IP地址等信息。可选地，监控模块510进一步适于：根据受控端信息列表中记录的主控端与受控端的连接信息，调用连通性测试命令判断受控端是否为存活状态。例如，在SaltStack工具中，调用test.ping命令。

写入模块520，适于将监控模块510获取的连接状态信息写入到数据库中。可选地，写入模块520将连通性命令执行后返回的非存活状态的受控端装置的信息写入到数据库中。

写入模块520写入的连接状态信息供受控端从数据库中读取，并供受控端根据连接状态信息判断主控端与受控端之间是否为不可用的连接状态。

清除模块530，适于根据主控端与受控端之间为不可用连接状态的信息反馈，在受控端信息列表中清除受控端的信息。

可选地，主控端服务器还包括：配置模块540，适于重新启动与受控端之间的连接过程；写入模块520进一步适于：根据重新启动的与受控端之间的连接的状态，及时更新数据库内写入的连接状态信息。

可选地，主控端服务器和受控端装置之间需要授信，配置模块540进一步适于：接收受控端重启连接服务后发送的第一公钥；认证该第一公钥并以第一公钥替换主控端保存的第二公钥。

图6示出了根据本发明一个实施例的受控端装置的结构示意图，如图6所示，该装置包括：读取模块610、判断模块620、重启模块630、以及通知模块640。

读取模块610，适于从数据库中读取连接状态信息，连接状态信息是由主控端通过监控主控端与受控端之间连接状态所获取并写入到数据库中。数据库中保存有主控端服务器写入的连接状态信息，如非存活的受控端装置的IP，主机名等。

判断模块620，适于根据连接状态信息判断主控端与受控端之间是否为不可用连接状态。

通知模块640，适于在判断出主控端与受控端之间为不可用连接状态时，对不可用连接状态进行信息反馈。

重启模块630，适于在判断出主控端与受控端之间为不可用连接状态时，重新启动与主控端之间的连接过程。

进一步的，通知模块640，适于在判断模块620判断出主控端与受控端之间为不可用连接状态之后，向主控端发送不可用连接状态的通知，以告知主控端在维护的受控端信息列表中清除该受控端的信息。

可选地，数据库中保存有主控端服务器写入的非存活状态的受控端的信息，读取模块610进一步适于：从数据库读取所述非存活状态的受控端的信息；判断模块620进一步适于：判断非存活状态的受控端信息与受控端自身信息是否匹配，若是，则判定主控端与受控端之间为不可用连接状态。

可选地，受控端装置还包括：更新模块650，适于保存的更新配置文件。配置文件中记录有受控端主机名和与受控端连接的主控端主机名等信息。

可选地，重启模块630进一步适于：生成第一公钥和第一私钥；以第一私钥替换所述受控端保存的第二私钥，并将所述第一公钥发送给所述主控端，以供所述主控端对所述第一公钥进行认证。

图7示出了根据本发明一个实施例的多主机管理系统的结构示意图，如图7所示，该多主机管理系统包括：上面实施例所述的主控端服务器500和受控端装置600，以及由主控端服务器和受控端装置访问的数据库700。

根据本发明上述实施例提供的主控端服务器，受控端装置和多主机管理系统，主控端服务器监控其与各受控端装置之间的连接状态，获取连接状态信息并写入数据库中，供受控端装置读取。若连接状态不可用，受控端装置读取后与主控端服务器重新进行连接的配置及授信。上述的方案中，受控端装置能够及时得知不可用的连接状态，并及时反馈给主控端服务器以清除该受控端装置的信息，保证主控端服务器和受控端装置之间的正常通信，提高了多主机管理系统的健壮性。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的多主机管理系统中的一些或者全部部件的一些或者全部功能。本发明还可以实现为适于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

A1、一种多主机管理系统的监控方法，所述方法包括：

监控主控端与受控端之间的连接状态；

将通过监控连接状态所获取的连接状态信息写入到数据库中，所述连接状态信息供所述受控端从所述数据库中读取并供所述受控端根据所述连接状态信息判断所述主控端与受控端之间是否为不可用连接状态；

根据所述主控端与所述受控端之间为不可用连接状态的信息反馈，在所述主控端维护的受控端信息列表中清除所述受控端的信息。

A2、根据A1所述的方法，其特征在于，在所述在主控端维护的受控端信息列表中清除所述受控端的信息之后，所述方法还包括：

重新启动与所述受控端之间的连接过程；

根据重新启动的与所述受控端之间的连接状态，及时更新数据库内写入的连接状态信息。

A3、根据A1或A2所述的方法，其特征在于，所述监控主控端与受控端之间的连接状态进一步为：根据所述受控端信息列表中记录的受控端的信息，调用连通性测试命令判断所述受控端是否为存活状态；

将通过监控连接状态所获取的连接状态信息写入到所述数据库中进一步为：将非存活状态的受控端的信息写入到所述数据库中。

A4、根据A2所述的方法，其特征在于，所述重新启动与所述受控端之间的连接过程进一步包括：

接收所述受控端重启连接服务后发送的第一公钥；

认证所述第一公钥并以所述第一公钥替换所述主控端保存的第二公钥。

B5、一种多主机管理系统的监控方法，所述方法包括：

从数据库中读取连接状态信息，所述连接状态信息是由主控端通过监控主控端与受控端之间连接状态所获取并写入到数据库中；

根据所述连接状态信息判断主控端与受控端之间是否为不可用连接状态；

若判断出所述主控端与受控端之间为不可用连接状态，对所述不可用连接状态进行信息反馈，并重新启动与主控端之间的连接过程。

B6、根据B5所述的方法，其特征在于，在判断出所述主控端与受控端之间为不可用连接状态之后，所述方法还包括：向所述主控端发送不可用连接状态的通知，以告知所述主控端在维护的受控端信息列表中清除所述受控端的信息。

B7、根据B5或B6所述的方法，其特征在于，所述数据库中保存有所述主控端写入的非存活状态的受控端的信息；

所述从数据库中读取连接状态信息进一步为：从所述数据库读取所述非存活状态的受控端的信息；

所述根据所述连接状态信息判断主控端与受控端之间是否为不可用连接状态进一步为：判断所述非存活状态的受控端信息与受控端自身信息是否匹配，若是，则判定主控端与受控端之间为不可用连接状态。

B8、根据B5-B7任一项所述的方法，其特征在于，所述受控端保存有用于记录受控端主机名和与受控端连接的主控端主机名的配置文件；

在所述重新启动与主控端之间的连接过程之后还包括：更新所述配置文件。

B9、根据B5-B8任一项所述的方法，其特征在于，所述重新启动与主控端之间的连接过程进一步包括：

生成第一公钥和第一私钥；

以所述第一私钥替换所述受控端保存的第二私钥，并将所述第一公钥发送给所述主控端，以供所述主控端对所述第一公钥进行认证。

C10、一种主控端服务器，包括：

监控模块，适于监控主控端与受控端之间的连接状态；

写入模块，适于将通过监控连接状态所获取的连接状态信息写入到数据库中，所述连接状态信息供所述受控端从所述数据库中读取并供所述受控端根据所述连接状态信息判断所述主控端与受控端之间是否为不可用连接状态；

清除模块，适于根据所述主控端与所述受控端之间为不可用连接状态的信息反馈，在所述主控端服务器维护的受控端信息列表中清除所述受控端的信息。

C11、根据C10所述的主控端服务器，其特征在于，所述主控端服务器还包括：配置模块，适于重新启动与所述受控端之间的连接过程；

所述写入模块进一步适于：根据重新启动的与所述受控端之间的连接状态，及时更新数据库内写入的连接状态信息。

C12、根据C10或C11所述的主控端服务器，其特征在于，所述监控模块进一步适于：根据所述受控端信息列表中记录的受控端信息，调用连通性测试命令判断所述受控端是否为存活状态；

所述写入模块进一步适于：将非存活状态的受控端装置的信息写入到所述数据库中。

C13、根据C11所述的主控端服务器，其特征在于，所述配置模块进一步适于：

接收所述受控端重启连接服务后发送的第一公钥；

认证所述第一公钥并以所述第一公钥替换所述主控端保存的第二公钥。

D14、一种受控端装置，所述装置包括：

读取模块，适于从所述数据库中读取连接状态信息，所述连接状态信息是由主控端通过监控主控端与受控端之间连接状态所获取并写入到数据库中；

判断模块，适于根据所述连接状态信息判断主控端与受控端之间是否为不可用连接状态；

通知模块，适于在判断出所述主控端与受控端之间为不可用连接状态时，对所述不可用连接状态进行信息反馈；

重启模块，适于在判断出所述主控端与受控端之间为不可用连接状态时，重新启动与主控端之间的连接过程。

D15、根据D14所述的受控端装置，其特征在于，所述通知模块进一步适于：在所述判断模块判断出所述主控端与受控端之间为不可用连接状态之后，向所述主控端发送不可用连接状态的通知，以告知所述主控端在维护的受控端信息列表中清除所述受控端的信息。

D16、根据D14或D15所述的受控端装置，其特征在于，所述数据库中保存有所述主控端服务器写入的非存活状态的受控端的信息；

所述读取模块进一步适于：从所述数据库读取所述非存活状态的受控端的信息；

所述判断模块进一步适于：判断所述非存活状态的受控端信息与受控端自身信息是否匹配，若是，则判定主控端与受控端之间为不可用连接状态。

D17、根据D14-D16任一项所述的受控端装置，其特征在于，所述受控端装置保存有用于记录受控端主机名和与受控端连接的主控端主机名的配置文件；

所述受控端装置还包括：更新模块，适于更新所述配置文件。

D18、根据D14-D17任一项所述的受控端装置，其特征在于，所述重启模块进一步适于：

生成第一公钥和第一私钥；

以所述第一私钥替换所述受控端保存的第二私钥，并将所述第一公钥发送给所述主控端，以供所述主控端对所述第一公钥进行认证。

E19、一种多主机管理系统，包括：C10-C13任一项所述的主控端服务器、D14-D18任一项所述的受控端装置以及由所述主控端服务器和受控端装置访问的数据库。

Claims (10)

1.一种多主机管理系统的监控方法，所述方法包括：

监控主控端与受控端之间的连接状态；

将通过监控连接状态所获取的连接状态信息写入到数据库中，所述连接状态信息供所述受控端从所述数据库中读取并供所述受控端根据所述连接状态信息判断所述主控端与受控端之间是否为不可用连接状态；

根据所述主控端与所述受控端之间为不可用连接状态的信息反馈，在所述主控端维护的受控端信息列表中清除所述受控端的信息。

2.根据权利要求1所述的方法，其特征在于，在所述在主控端维护的受控端信息列表中清除所述受控端的信息之后，所述方法还包括：

重新启动与所述受控端之间的连接过程；

根据重新启动的与所述受控端之间的连接状态，及时更新数据库内写入的连接状态信息。

3.根据权利要求1或2所述的方法，其特征在于，所述监控主控端与受控端之间的连接状态进一步为：根据所述受控端信息列表中记录的受控端的信息，调用连通性测试命令判断所述受控端是否为存活状态；

将通过监控连接状态所获取的连接状态信息写入到所述数据库中进一步为：将非存活状态的受控端的信息写入到所述数据库中。

4.根据权利要求2所述的方法，其特征在于，所述重新启动与所述受控端之间的连接过程进一步包括：

接收所述受控端重启连接服务后发送的第一公钥；

认证所述第一公钥并以所述第一公钥替换所述主控端保存的第二公钥。

5.一种多主机管理系统的监控方法，所述方法包括：

从数据库中读取连接状态信息，所述连接状态信息是由主控端通过监控主控端与受控端之间连接状态所获取并写入到数据库中；

根据所述连接状态信息判断主控端与受控端之间是否为不可用连接状态；

若判断出所述主控端与受控端之间为不可用连接状态，对所述不可用连接状态进行信息反馈，并重新启动与主控端之间的连接过程。

6.根据权利要求5所述的方法，其特征在于，在判断出所述主控端与受控端之间为不可用连接状态之后，所述方法还包括：向所述主控端发送不可用连接状态的通知，以告知所述主控端在维护的受控端信息列表中清除所述受控端的信息。

7.一种主控端服务器，包括：

监控模块，适于监控主控端与受控端之间的连接状态；

写入模块，适于将通过监控连接状态所获取的连接状态信息写入到数据库中，所述连接状态信息供所述受控端从所述数据库中读取并供所述受控端根据所述连接状态信息判断所述主控端与受控端之间是否为不可用连接状态；

清除模块，适于根据所述主控端与所述受控端之间为不可用连接状态的信息反馈，在所述主控端服务器维护的受控端信息列表中清除所述受控端的信息。

8.根据权利要求7所述的主控端服务器，其特征在于，所述主控端服务器还包括：配置模块，适于重新启动与所述受控端之间的连接过程；

所述写入模块进一步适于：根据重新启动的与所述受控端之间的连接状态，及时更新数据库内写入的连接状态信息。

9.一种受控端装置，所述装置包括：

读取模块，适于从所述数据库中读取连接状态信息，所述连接状态信息是由主控端通过监控主控端与受控端之间连接状态所获取并写入到数据库中；

判断模块，适于根据所述连接状态信息判断主控端与受控端之间是否为不可用连接状态；

通知模块，适于在判断出所述主控端与受控端之间为不可用连接状态时，对所述不可用连接状态进行信息反馈；

重启模块，适于在判断出所述主控端与受控端之间为不可用连接状态时，重新启动与主控端之间的连接过程。

10.一种多主机管理系统，包括：权利要求7或8所述的主控端服务器、权利要求9所述的受控端装置以及由所述主控端服务器和受控端装置访问的数据库。