判定服务节点状态的方法
【专利摘要】本发明提供一种判定服务节点状态的方法，适用于数据平行运算架构中。所述方法包含下列步骤：第一服务节点通过第一数据通信接口连接第二服务节点；利用第一服务节点判定从第二服务节点反馈的第一连接信息；当第一连接信息代表第一服务节点与第二服务节点之间无法连接时，第一服务节点通过第二数据通信接口连接第二服务节点；以及利用第一服务节点判定从第二服务节点反馈的第二连接信息，进而判定第二服务节点的状态以执行状态对应程序，以避免耗费大量等待时间。
【专利说明】判定服务节点状态的方法
【技术领域】
[0001]本发明关于一种判定服务节点状态的方法，特别是应用在一种数据平行运算架构中。
【背景技术】
[0002]目前，巨量数据平行运算架构如Hadoop是实现大数据(bigdata)的平行及分散运算中最常见的平台，处于以多个服务节点如伺服器所构成的群组环境中，当进行数据(如应用程序)的平行及分散运算时，多个服务节点间必须要互相等待，互相判定每个服务节点是否逾时而未反应，故需要有判定服务节点之间连线是否逾时或某个服务节点故障(当机)的方法。
[0003]参考图1，一种现有数据平行运算架构的架构图，数据平行运算架构100包括第一服务节点10与第二服务节点20之间通过网络通信接口 15如TCP/IP通信接口进行连接，第一服务节点10与第二服务节点20可以是伺服器。一般而言，每两个服务节点之间会协定重新连接次数(如2次)与每两次重新连接之间的预设等待时间。当达到重新连接次数的上限而仍然没有得到回应时，第一服务节点10才会得到逾时(Timeout)信号。然而，因为每一个服务节点如第二服务节点20的处理器可能因为忙碌而无法回应，以致预设等待时间都会设定为数分钟，但在Hadoop此类大量运算的节点群组架构中，只要其中任一服务节点故障(当机)，就需等待到达重新连接次数的上限以及每两次重新连接之间的预设等待时间，才能够判定服务节点故障(当机)，故而需要耗费大量的等待时间。
[0004]参考图2，另一现有数据平行运算架构的架构图，其与图1所示的架构图区别在于:图2中数据平行运算架构200的第一服务节点10与第二服务节点20之间额外设置交换器30，例如常见的ARISTA网络交换器，这使每一服务节点10，20之间不直接互连，而是各别先连接交换器30。当某一服务节点10或20故障(当机)时，交换器30会送出合乎TCP/IP通信接口规范的重置信号告知欲连到故障(当机)的服务节点的其他服务节点，让其他服务节点不需要等待便可知道故障(当机)的服务节点的状态，进而连接别的服务节点，但其缺点在于需要额外设置交换器30，会增加建置成本。
【发明内容】
[0005]本发明的目的在于提供一种判定服务节点状态的方法，适用在数据平行运算架构(如Hadoop)中，能避免现有技术单纯使用TCP/IP通信接口确认各服务节点是否故障以致耗费过长等待时间(包括重新连接的次数与每两次重新连接之间的预设等待时间)的问题；同时，本发明无需在数据平行运算架构中额外设置交换器，故能降低建置交换器的硬件成本。
[0006]为了达成上述目的，本发明提供一种判定服务节点状态的方法，适用于一种数据平行运算架构中，架构包含第一服务节点与第二服务节点，第一服务节点包含第一处理器与第一基板管理控制器，以及第二服务节点包含第二处理器与第二基板管理控制器。
[0007]本发明提供的一种判定服务节点状态的方法包括下列步骤:首先，第一服务节点通过第一数据通信接口连接第二服务节点。接着，利用第一服务节点判定从第二服务节点反馈的第一连接信息。接着，当第一连接信息代表第一服务节点与第二服务节点之间无法连接时，第一服务节点通过第二数据通信接口连接第二服务节点。接着，利用第一服务节点判定从第二服务节点反馈的第二连接信息，进而判定第二服务节点的状态以执行状态对应程序，避免耗费大量等待时间。
[0008]在一优选实施例中，数据平行运算架构为Hadoop。
[0009]在一优选实施例中，第一数据通信接口为TCP/IP通信接口。
[0010]在一优选实施例中，在利用第一服务节点判定从第二服务节点反馈的第一连接信息的步骤中进一步包括:第一服务节点判定第一连接信息是否为逾时信息，逾时信息用于显示第一服务节点与第二服务节点之间的一次性连接已超过预设的等待时间。
[0011 ] 在一优选实施例中，第二数据通信接口为符合智能平台管理接口规范的数据通信接口。以及第一服务节点通过第二数据通信接口连接第二服务节点的步骤进一步包括:第一服务节点的第一基板管理控制器通过第二数据通信接口至第二服务节点的第二基板管理控制器进而判定第二服务节点的第二处理器是否处于运行状态。
[0012]在一优选实施例中，利用第一服务节点判定从第二服务节点反馈的第二连接信息的步骤进一步包括:利用第一服务节点的第一基板管理控制器判定从第二服务节点的第二基板管理控制器通过第二数据通信接口反馈的符合智能平台管理接口规范的第二连接信肩、O
[0013]在一优选实施例中，利用第一服务节点判定从第二服务节点反馈的第二连接信息，进而判定第二服务节点的状态以执行状态对应程序的步骤进一步包括:当第一服务节点判定出第二连接信息代表第一服务节点与第二服务节点之间无法连接及/或第二服务节点并非处于运行状态时，则判定第二服务节点处于已故障的状态。
[0014]在上述优选实施例中，状态对应程序包括:使第一服务节点中止连接第二服务节点。
[0015]在上述优选实施例中，状态对应程序包括:使第一服务节点连接数据平行运算架构中的第三服务节点。
[0016]在一优选实施例中，利用第一服务节点判定从第二服务节点反馈的第二连接信息进而判定第二服务节点的状态以执行状态对应程序的步骤进一步包括:当第一服务节点判定出第二连接信息代表第二服务节点的第二处理器处于高度运算状态时，则判定第二服务节点处于忙碌状态且状态对应程序包括:使第一服务节点进入预设的等待程序以等待重新连接第二服务节点。
[0017]本发明的优点在于:相较于现有技术，由于本发明进一步通过智能平台管理接口连接各服务节点的基板管理控制器，能避免单纯使用TCP/IP通信接口确认各服务节点是否故障所需耗费的等待时间(包括重新连接的次数与每两次重新连接之间的预设等待时间)，特别是在进行大数据的运算时，能够节省大量的等待时间；同时，本发明无需在数据平行运算架构中额外设置交换器，故能降低建置交换器的硬件成本。
【专利附图】
【附图说明】
[0018]图1，一种现有数据平行运算架构的架构图；
[0019]图2，另一种现有数据平行运算架构的架构图；
[0020]图3，本发明一实施例所述的数据平行运算架构的架构图；
[0021]图4，本发明一实施例所述的判定服务节点状态的方法流程图。
[0022]【符号说明】
[0023]10,310:第一服务节点；15:网络通信接口；
[0024]20、320:第二服务节点；30:交换器；
[0025]100、200、300:数据平行运算架构；
[0026]311:第一处理器；312:第一基板管理控制器；
[0027]321:第二处理器；322:第二基板管理控制器；
[0028]330:第一数据通信接口； 340:第二数据通信接口；
[0029]350:第三服务节点；
[0030]351:第三处理器；352:第三基板管理控制器；
[0031]S01-S10:步骤。
【具体实施方式】
[0032]以下各实施例的说明是结合附图，用以说明本发明可用以实施的特定实施例。本发明所提到的方向用语，例如「上」、「下」、「前」、「后」、「左」、「右」、「内」、「外」、「侧面」等，仅是参考附图的方向。因此，使用的方向用语是用以说明及理解本发明，而非用以限制本发明。
[0033]参考图3，本发明一实施例所述的数据平行运算架构的架构图。在本实施例中，数据平行运算架构300包含第一服务节点310与第二服务节点320，第一服务节点310包含第一处理器311与第一基板管理控制器312，以及第二服务节点320包含第二处理器321与第二基板管理控制器322。本实施例所述的数据平行运算架构300中，第一服务节点310与第二服务节点320之间的初始连接先采用第一数据通信接口 330的方式进行数据的传送/接收，第一数据通信接口 330为TCP/IP通信接口或其他现有网络通信接口 ；在本实施例中，通过TCP/IP通信接口，每两个服务节点310，320之间仅协定一次性连接且一次性连接包括预设等待时间(如以3分钟的预设等待时间计算，I次x3分钟=3分钟的总等待时间)以供判定一次性连接是否逾时，而不同于现有数据平行运算架构的每两个服务节点之间的连接要达到重新连接次数的上限(如2次)以及每两次重新连接之间的预设等待时间(如以3分钟的预设等待时间计算，2次x3分钟=6分钟的总等待时间)的状况下，没有得到回应服务节点才会得到逾时(Timeout)信号。
[0034]接着，利用第二服务节点320通过第一数据通信接口 330反馈的符合TCP/IP接口规范的第一连接信息来判定第一服务节点310与第二服务节点320是否能够顺利连接，其中进一步包括:第一服务节点310判定第一连接信息是否为逾时信息，逾时信息用于显示第一服务节点310与第二服务节点320之间的一次性连接已超过预设等待时间(如3分钟的预设等待时间)。
[0035]参考图3，当第一服务节点310从第一连接信息判定出第一服务节点310与第二服务节点320无法顺利连接(如逾时)时，不同于现有技术是持续通过TCP/IP通信接口重新连接第二服务节点320才能最终判定第二服务节点320是故障(当机)或是忙碌，本发明是接着利用第一服务节点310通过第二数据通信接口 340连接第二服务节点320，再由第一服务节点310判定从第二服务节点320通过第二数据通信接口 340反馈的第二连接信息，使第一服务节点310判定第二服务节点320所处的状态为何，如是已故障(当机)状态或忙碌状态，再根据上述状态的判定结果执行状态对应程序；在本实施例中，第二数据通信接口 340为符合智能平台管理接口(IPMI)规范的数据通信接口，当第一服务节点310通过第二数据通信接口 340连接第二服务节点320时，通过第一服务节点310的第一基板管理控制器311通过第二数据通信接口 340连接第二服务节点320的第二基板管理控制器321以判定第二服务节点320的第二处理器322是否处于运行状态，进而使第二服务节点320的第二基板管理控制器321通过第二数据通信接口 340反馈符合智能平台管理接口(IPMI)规范的第二连接信息，使第一服务节点310的第一基板管理控制器311从第二连接信息中判定第二服务节点320的第二处理器322所处的状态为何(如已故障(当机)状态或忙碌状态)。
[0036]在本实施例中，当第一服务节点310判定出从第二服务节点320反馈的第二连接信息代表第一服务节点310与第二服务节点320之间无法连接及/或第二服务节点320并非处于运行时，则判定第二服务节点320的第二处理器322处于已故障的状态以执行状态对应程序，状态对应程序包括:使第一服务节点310中止连接第二服务节点320，以及/或者使第一服务节点310连接数据平行运算架构300中的第三服务节点350。因为第一服务节点310连接到第三服务节点350的过程中，与第一服务节点310连接到第三服务节点350的过程相同，且第三服务节点350同样也包含第三处理器351与第三基板管理控制器352，因此以下不再赘述。
[0037]在另一实施例中，利用第一服务节点310判定从第二服务节点320反馈的第二连接信息进而判定第二服务节点320的状态以执行状态对应程序进一步包括:当第一服务节点310判定出从第二服务节点320反馈的第二连接信息代表第二服务节点320的第二处理器处321于高度运算状态时，则判定第二服务节点320处于忙碌状态以执行状态对应程序，且状态对应程序包括:使第一服务节点310进入预设的等待程序以等待重新连接第二服务节点320。
[0038]参考图4，本发明一实施例所述的判定服务节点状态的方法流程图，应用于如图3所示的数据平行运算架构300及其组成元件。以下对本实施例所述的方法所包括的步骤进行说明。
[0039]首先，执行步骤S01，使第一服务节点310通过第一数据通信接口 330连接第二服务节点320。
[0040]接着，执行步骤S02，第一服务节点310通过第一数据通信接口 330接收从第二服务节点320反馈的第一连接信息。
[0041]接着，执行步骤S03，利用第一服务节点310判定第一数据通信接口 330连接是否逾时以判定第一连接信息是否为逾时信息(判定第一连接信息是否为逾时信息的方法如前述)。若否，执行步骤S10，进行第一服务节点310与第二服务节点320之间的数据传输。
[0042]若判定第一连接信息是逾时信息，即当第一连接信息代表第一服务节点与第二服务节点之间无法连接时，则执行步骤S04，第一服务节点310通过第二数据通信接口 340连接第二服务节点320。第二数据通信接口 340为符合智能平台管理接口(IPMI)规范的数据通信接口。在这个步骤中，第一服务节点310的第一基板管理控制器312通过第二数据通信接口 340连接第二服务节点320的第二基板管理控制器322进而判定第二服务节点320的第二处理器321是否处于运行状态。
[0043]接着，执行步骤S05，第一服务节点310接收从第二服务节点320反馈的第二连接信息，进而判定第二服务节点的状态以执行状态对应程序。利用第一服务节点310的第一基板管理控制器312判定从第二服务节点320的第二基板管理控制器322通过第二数据通信接口 340反馈的符合智能平台管理接口(IPMI)规范的第二连接信息。
[0044]接着，执行步骤S06，根据第二连接信息判定第二服务节点320是否处于运行状态。若是，即当第一服务节点310判定出第二连接信息代表第二服务节点320的第二处理器321处于高度运算状态时，则执行步骤S07，判定第二服务节点320处于忙碌状态并执行状态对应程序，使第一服务节点310进入预设的等待程序以等待重新连接第二服务节点320。
[0045]若不是，即当第一服务节点310判定出第二连接信息代表第一服务节点310与第二服务节点320之间无法连接及/或第二服务节点320并非处于运行状态时，则执行步骤S08，判定第二服务节点320处于已故障的状态并执行状态对应程序，使第一服务节点310中止连接第二服务节点320。接着，执行步骤S09，使第一服务节点310连接第三服务节点350。
[0046]综上所述，通过本发明所述的判定服务节点状态的方法及数据平行运算架构(如Hadoop)，能避免现有技术单纯使用TCP/IP接口确认各服务节点是否故障以致耗费过长等待时间(包括重新连接的次数与每两次重新连接之间的预设等待时间)的问题；同时，本发明无需在数据平行运算架构中额外设置交换器，故能降低建置交换器的硬件成本。
[0047]以上所述仅是本发明的优选实施方式，应当指出，对于本【技术领域】的普通技术人员，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。
【权利要求】
1.一种判定服务节点状态的方法，应用于数据平行运算架构，包含一第一服务节点与一第二服务节点，所述第一服务节点包含一第一处理器与一第一基板管理控制器，以及所述第二服务节点包含一第二处理器与一第二基板管理控制器，所述方法包含: 所述第一服务节点通过一第一数据通信接口连接所述第二服务节点； 利用所述第一服务节点判定从所述第二服务节点反馈的一第一连接信息； 当所述第一连接信息代表所述第一服务节点与所述第二服务节点之间无法连接时，所述第一服务节点通过一第二数据通信接口连接所述第二服务节点；以及 利用所述第一服务节点判定从所述第二服务节点反馈的一第二连接信息，进而判定所述第二服务节点的状态以执行一状态对应程序。
2.根据权利要求1所述的方法，其特征在于，所述数据平行运算架构为Hadoop。
3.根据权利要求1所述的方法，其特征在于，所述第一数据通信接口为TCP/IP通信接□。
4.根据权利要求3所述的方法，其特征在于，在利用所述第一服务节点判定从所述第二服务节点反馈的所述第一连接信息的步骤中进一步包括，利用所述第一服务节点判定所述第一连接信息是否为一逾时信息，所述逾时信息用于显示所述第一服务节点与所述第二服务节点之间的一次性连接已超过一预设的等待时间。
5.根据权利要求1所述的方法，其特征在于，所述第二数据通信接口为一符合智能平台管理接口规范的数据通信接口，以及所述第一服务节点通过所述第二数据通信接口连接所述第二服务节点的步骤进一步包括:所述第一服务节点的第一基板管理控制器通过所述第二数据通信接口连接所述第二服务节点的第二基板管理控制器进而判定所述第二服务节点的所述第二处理器是否处于运行状态。
6.根据权利要求5所述的方法，其特征在于，利用所述第一服务节点判定从所述第二服务节点反馈的所述第二连接信息的步骤进一步包括:利用所述第一服务节点的所述第一基板管理控制器判定从所述第二服务节点的第二基板管理控制器通过所述第二数据通信接口反馈的一符合智能平台管理接口规范的所述第二连接信息。
7.根据权利要求1所述的方法，其特征在于，利用所述第一服务节点判定从所述第二服务节点反馈的所述第二连接信息，进而判定所述第二服务节点的状态以执行所述状态对应程序的步骤进一步包括:当所述第一服务节点判定出所述第二连接信息代表所述第一服务节点与所述第二服务节点之间无法连接及/或所述第二服务节点并非处于运行状态时，则判定所述第二服务节点处于已故障的状态。
8.根据权利要求7所述的方法，其特征在于，所述状态对应程序包括:使所述第一服务节点中止连接所述第二服务节点。
9.根据权利要求7所述的方法，其特征在于，所述状态对应程序包括:使所述第一服务节点连接所述数据平行运算架构中的一第三服务节点。
10.根据权利要求1所述的方法，其特征在于，利用所述第一服务节点判定从所述第二服务节点反馈的所述第二连接信息，进而判定所述第二服务节点的状态以执行一状态对应程序的步骤进一步包括:当所述第一服务节点判定出所述第二连接信息代表所述第二服务节点的第二处理器处于高度运算状态时，则判定所述第二服务节点处于一忙碌状态且所述状态对应程序包括:使所述第一服务节点进入一预设的等待程序以等待重新连接所述第二服务节点。
【文档编号】H04L12/24GK104378237SQ201410680627
【公开日】2015年2月25日 申请日期:2014年11月24日 优先权日:2014年11月24日
【发明者】孙佑良 申请人:英业达科技有限公司, 英业达股份有限公司