运用于数据中心的机柜异常状态的远端排除方法与流程

本发明涉及数据中心，尤其涉及对数据中心中的机柜的异常状态的分析与排除的方法。
背景技术：
：一般来说，一个数据中心通常会通过智能型平台管理界面(intelligentplatformmanagementinterface,ipmi)对数据中心内的机柜、端点服务器等设备的机柜管理控制器(rackmanagementcontroller,rmc)及基板管理控制器(baseboardmanagementcontroller,bmc)进行远端管理。不论使用何种方式进行远端管理，只要任一机柜或端点服务器的rmc或bmc出现异常，管理者就会收到许多警告信件。然而，管理者一般难以通过这些警告信件在第一时间直接得知状态的真正问题点，往往需要随着时间不断推进，直到收到数百封警告信件并且与设备失去连线后，才能确定所述rmc、bmc发生了异常。更甚者，即使部分的管理平台从不同的监控管道收集到错误信息，并且进行汇整后提交故障评估报告给管理者，但这样的监控方式仍然需要由管理者进行最后的判断，并且决定处理方式。然而，只要有人为因素的介入，就无法全然避免误判的可能。有鉴于此，本领域确实需要发展一套新颖的系统与方法，可针对处于异常状态的rmc及bmc自动实施远端修复机制，藉此强化数据中心的监控能力，使得机柜管理能够高度自动化，同时减少人为判定所间接流失的时间，并且避免人为误判。技术实现要素：本发明的主要目的，在于提供一种运用于数据中心的机柜异常状态的远端排除方法，可以在判断机柜管理控制器或基板管理控制器已处于异常状态但尚未失去连线时，直接于远端自动解除所述异常状态。为了达成上述的目的，本发明的远端排除方法是运用于具有一机柜及由远端与该机柜连接的一机柜服务器管理系统的一数据中心，其中该机柜具有一机柜管理控制器(rackmanagementcontroller,rmc)及多个端点服务器，各该端点服务器分别具有一基板管理控制器(baseboardmanagementcontroller,bmc)，该远端排除方法包括：a)该机柜服务器管理系统定时存取一数据库以取得该rmc及各该bmc的状态数据及事件日志(eventlog)，以及一管理者通过该机柜服务器管理系统对该机柜所执行的操作行为；b)依据该状态数据、该事件日志及该操作行为判断该rmc及各该bmc的其中之一是否处于预设的多种关注状态的其中之一；及c)于判断任一rmc或bmc处于该多种关注状态中的一第一类关注状态时，该机柜服务器管理系统自动对处于该第一类关注状态的该rmc或该bmc实施一远端恢复机制，以解除该rmc或该bmc的异常状态，其中该第一类关注状态指该rmc或该bmc已处于该异常状态，但尚未与该机柜服务器管理系统失去连线。如上所述，其中更包括下列步骤：a01)该机柜服务器管理系统启动；a02)该步骤a01)后，该机柜服务器管理系统定时主动远程访问该机柜内的该rmc及各该bmc；a03)取得该rmc及各该bmc的该状态数据及该事件日志；a04)将该状态数据及该事件日志储存至该数据库；及a05)于该机柜服务器管理系统关闭前持续执行该步骤a02)至该步骤a04)。如上所述，其中更包括下列步骤：a11)该机柜服务器管理系统启动；a12)该步骤a11)后，该机柜服务器管理系统提供一操作界面；a13)于通过该操作界面接受该管理者的该操作行为时，依据该操作行为的内容对该rmc及各该bmc实施一远端管理程序；a14)取得该远端管理程序对应的反馈信息；a15)将该操作行为及该反馈信息储存至该数据库；及a16)于该机柜服务器管理系统关闭前持续执行该步骤a12)至该步骤a15)。如上所述，其中该步骤b)是判断该事件日志中是否有任一事件的事件发生时间错误，并且于任一rmc或bmc的任一事件的事件发生时间错误时，视为该rmc或该bmc处于该第一类关注状态。如上所述，其中机柜服务器管理系统是于该事件日志中的任一事件的事件发生时间为pre-init时，判断该事件的事件发生时间错误。如上所述，其中该步骤c)包括下列步骤：c11)于判断任一rmc或bmc处于该第一类关注状态时，取得该机柜服务器管理系统本次存取该事件日志的一时间戳记；及c12)将该时间戳记做为该事件的一备位时间识别信息并储存于该数据库中；其中，当该管理者通过一操作界面于该机柜服务器管理系统中查询该事件日志时，该机柜服务器管理系统显示该备位时间识别信息以做为该事件的该事件发生时间。如上所述，其中该步骤c)更包括下列步骤：c13)该机柜服务器管理系统发出一第一控制指令至处于该第一类关注状态的该rmc或该bmc，以对该rmc或该bmc执行一时间校正程序。如上所述，其中该时间校正程序是通过网络时间协定(networktimeprotocol,ntp)校正该rmc或该bmc的时间，或强制该rmc或该bmc进行重置作业。如上所述，其中该步骤b)包括下列步骤：b1)依据该操作行为判断该管理者是否对该rmc及各该bmc实施了一更新作业，其中该rmc及各该bmc于接受该更新作业的操作时自动进入一更新模式；b2)依据该状态数据或该事件日志判断该rmc及各该bmc的该更新作业是否逾时或发生错误；b3)依据该状态数据判断该rmc及各该bmc的网络连线是否正常；及b4)于任一rmc或bmc执行了该更新作业、该更新作业逾时或发生错误、并且该网络连线正常时，视为该rmc或该bmc处于该第一类关注状态。如上所述，其中该步骤c)包括下列步骤：c21)该机柜服务器管理系统发出一第二指令至处于该第一类关注状态的该rmc或该bmc，以强制该rmc或该bmc离开该更新模式；及c22)该步骤c21)后，该机柜服务器管理系统发出一第三指令至处于该rmc或该bmc，以强制该rmc或该bmc进行重置作业或再次实施该更新作业。相对于相关技术，本发明的方法由与机柜连线的机柜服务器管理系统来进行分析并自动实施远端恢复机制，无需等待管理者对于异常状态的人为判定，可大幅降低管理成本，亦使得机柜的监控无需人为干涉，也不受距离与时间的影响。以下结合附图和具体实施例对本发明进行详细描述，但不作为对本发明的限定。附图说明图1为本发明的数据中心的示意图；图2为本发明的机柜的方框图的第一具体实施例；图3a为本发明的数据搜集流程图的第一具体实施例；图3b为本发明的数据搜集流程图的第二具体实施例；图4为本发明的分析与排除流程图的第一具体实施例；图5为本发明的第一类关注状态排除流程图的第一具体实施例；图6为本发明的第一类关注状态排除流程图的第二具体实施例；图7为本发明的第二类关注状态排除流程图的第一具体实施例；图8为本发明的第三类关注状态排除流程图的第一具体实施例。其中，附图标记：1…数据中心；2…机柜；21…机柜管理控制器；211、221…网络接口控制器；22…基板管理控制器；220…端点服务器；23…内部网络交换机；24…内部硬件线路；3…机柜服务器管理系统；31…数据库；4…公共网络交换机；s11～s15、s21～s28…搜集步骤；s31～s39…分析与排除步骤；s41～s47、s51～s58、s61～s66、s71～s80…排除步骤。具体实施方式兹就本发明之一较佳实施例，配合附图，详细说明如后。本发明揭露了一种机柜异常状态的远端排除方法(下面将于说明书中简称为排除方法)，所述排除方法主要运用于数据中心内，以协助管理者自动监控、分析并且排除数据中心内的异常状态。参阅图1，为本发明的数据中心的示意图。如图1所示，本发明所述的数据中心1主要具有多个机柜2，以及由远端与多个机柜2连线的机柜服务器管理系统3(下面简称为管理系统3)。所述管理系统3可设置于数据中心1的内部或外部，并且经由网络连接公共网络交换机4，再经由公共网络交换机4连接数据中心1内的多个机柜2。本发明的管理系统3可实时监控数据中心1内的多个机柜2、获取多个机柜2的各项信息、并且对这些信息进行分析。当发现任一机柜2发生异常状态或即将发生异常状态时，本发明的管理系统3可自动实施对应的处理机制以进行状况排除。藉此，本发明可以在完全不需要人为介入、大幅降低人为误判并且提升处理速度的前提下，对机柜2已发生的异常状态进行排除，或对可能即将发生的异常状态进行预防。于一实施例中，所述管理系统3可为个人电脑或云端服务器，内部具有一或多个中央处理单元(图未标示)。管理系统3被启动后，可通过公共网络交机4连接至数据中心1内的多个机柜2，并可藉由一或多个中央处理单元执行特定的应用程序与演算法，以实现对这些机柜2的监控、数据分析及异常状态排除。所述管理系统3还具有数据库31，用以暂存或永久保存从数据中心1内的多个机柜2所获得的各项信息。于图1的实施例中，所述数据库31是内建于管理系统3。于其他实施例中，管理系统3亦可从外部连接一或多个数据库31，不加以限定。参阅图2，为本发明的机柜的方框图的第一具体实施例。图2的实施例中以数据中心1内的单一台机柜2连接至所述管理系统3为例，进行说明，然而数据中心1系可依实际所需设置多台的机柜2，而不以图2所示者为限。如图2所示，本发明的机柜2内主要包括至少一个机柜管理控制器(rackmanagementcontroller,rmc)21，以及与rmc21连接的多台端点服务器220，其中各个端点服务器220分别具备至少一个基板管理控制器(baseboardmanagementcontroller,bmc)22。所述rmc21为一种嵌入式系统，设置于机柜2内，通过各式硬件线路协助处理机柜2的内部硬件设备(降温风扇，各式感测器或电源供应器等等设备)的所有对外通讯，并与机柜2内的所有端点服务器220的bmc22进行沟通。所述bmc22也为嵌入式系统，设置于端点服务器220中并协助处理端点服务器220的内部硬件设备(各式感测器等等设备)的所有对外通讯。本实施例中，rmc21通过内部硬件线路24连接机柜2内的所有端点服务器220的bmc22，藉由与各个bmc22沟通来控制各个端点服务器220并且获取所需信息。本实施例中，所述端点服务器可例如为直立式服务器(towermodelserver)或刀锋服务器(bladeserver)等，但不加以限定。如图2所示，设置在机柜2内的每一个端点服务器220分别具有一个固定的位置号码(如图2中的#1、#2、#n等)，当端点服务器220或是bmc22对外的网络功能失效时，rmc21可通过内部硬件线路24连接至机柜2内的指定位置(如上述的#1、#2、#n)，进而与该指定位置上的端点服务器220及bmc22沟通。如此一来，即使端点服务器220或是bmc22失去网络连线，机柜2仍可藉由rmc21来进行监控、管理各个bmc22并且排除各个bmc22的异常状况。另，本发明的rmc21内设置有网络接口控制器(networkinterfacecontroller,nic)211，各个bmc22内亦分别设置有网络接口控制器221。rmc21通过nic211连接机柜2内部的内部网络交换机23，各个bmc22分别通过各自的nic221连接所述内部网络交换机23。机柜2通过内部网络交换机23连接公共网络交换机4，并且藉由公共网络交换机4与所述管理系统3建立网络连线。如此一来，管理系统3可经由网络远程访问数据中心1内的机柜2，藉此查询并获取机柜2内的所有rmc21及bmc22的各项信息，并且储存于数据库31内。本发明的主要技术特征在于，管理系统3可经由网络定时访问机柜2，并获取机柜2内所有rmc21及bmc22的各项信息(例如状态数据、事件日志(eventlog)、系统资源使用率、端点服务器220内部感测器的感测数值等等)，藉由这些信息来主动分析rmc21及bmc22是否发生异常状态，或即将发生异常状态。当管理系统3经分析后认为有必要时，即可主动于远端实施对应的机制，以于远端直接排除rmc21及/或bmc22的异常状态，或是预先避免rmc21及/或bmc22进入所述异常状态。本发明的技术方案可以在完全不需人为介入的情况下进行异常状态的处理，大幅降低了人为误判的可能，并且可令机柜2的监控达到高度自动化。续请参阅图3a，为本发明的数据搜集流程图的第一具体实施例。如图3a所示，若管理者欲对数据中心1内的机柜2进行监控，则管理者可直接启动远端的管理系统3(步骤s11)。当管理系统3被启动后，即会主动远程访问数据中心1中的机柜2(以图2中的单一个机柜2为例)内的rmc21及所有bmc22(步骤s12)。并且，管理系统3藉由远程访问来取得机柜2中的rmc21及所有bmc22的各项信息(步骤s13)，再将所取得的信息储存于本地端的数据中31中(步骤s14)。具体地，本实施例中，管理系统3是在启动后定时主动访问机柜2，也就是将步骤s12、s13、s14的访问动作、信息取得动作及储存动作视为启动后的例行程序(routine)。于执行上述routine时，持续判断管理系统3是否关闭(步骤s15)，并且于管理系统3关闭前持续执行上述步骤s12至步骤s14，以持续对机柜2内的rmc21与bmc22进行监控。参阅图3b，为本发明的数据搜集流程图的第二具体实施例。本实施例中，当管理者启动了所述管理系统3后(步骤s21)，管理系统3可以提供一个操作界面(步骤s22)。通过这个操作界面，管理者可以登入管理系统3，并且藉由管理系统3来于远端对数据中心1中的各个机柜2进行信息监控以及控制。本实施例中，所述操作界面可为一个实体界面或网页(web)界面，不加以限定。在提供了所述操作界面后，管理系统3持续判断是否通过操作界面接受了由管理者所进行的操作(步骤s23)。若确实接受到管理者的操作，则管理系统3依据管理者的操作行为，从远端对机柜2以及机柜2内的rmc21及bmc22实施对应的远端管理(步骤s24)。接着，管理系统3可记录管理者的上述操作行为(步骤s25)，并且，还可取得并记录管理系统3、机柜2、各端点服务器220以及rmc21、bmc22因为所述远端管理而产生的反馈、系统参数及执行数据等反馈信息(步骤s26)。最后，管理系统3同样将所述操作行为及反馈信息储存于数据库31中(步骤s27)，以利于后续对于异常状态的分析动作。相同地，本实施例的管理系统3会将步骤s22至步骤s27的动作视为启动后的routine。于执行上述routine时，持续判断管理系统3是否关闭(步骤s28)，并且于管理系统3关闭前持续执行上述步骤s22至步骤s27，以持续监控并分析管理者所实施的操作行为对机柜2内的rmc21与bmc22所造成的影响。续请参阅图4，为本发明的分析与排除流程图的第一具体实施例。如图4所示，本实施例中管理系统3会定时存取数据库31(步骤s31)，并且从数据库31中取得机柜2中的rmc21及bmc22各项信息、管理者的操作行为、以及各项反馈信息(步骤s32)，并且加以进行分析。藉由上述数据，管理系统3可以分析出机柜2内的rmc21及各个bmc22是否处于预设的多种关注状态的其中之一(步骤s33)。于一实施例中，所述管理系统3可以实时地取得机柜2中的rmc21与bmc22的各项信息、实时地从操作界面取得管理者的操作行为，并且据以进行分析。于另一实施例中，管理系统3可藉由图3a的步骤s14及图3b的步骤s27定时将上述数据储存至数据库31中，并且定时从数据库31中读取上述数据以进行分析，不加以限定。于一实施例中，上述rmc21及bmc22的各项信息，可例如为状态数据(如目前处于工作模式或更新模式、ip地址、mac地址、子网络遮罩、闸道器ip地址、ipmisession数量等)、事件日志(eventlog)等，而上述操作行为可例如为管理者针对特定机柜2、端点服务器220或rmc21、bmc22所实行的数据查询作业、更新作业、重置作业等，但不加以限定。通过上述数据，管理系统3可以藉由执行对应演算法而分析出机柜2中目前是否具有需要即时救援的rmc21或bmc22。于图4的实施例中，管理系统3主要可预设至少三个种类的关注状态，包括第一类关注状态、第二类关注状态及第三类关注状态，其中这三类的关注状态分别对应至rmc21/bmc22不同的异常状况，并且分别需要由管理系统3于远端直接实施不同的机制来加以排除或加以预防。如图4所示，若管理系统3依据上述数据(主要依据状态数据、事件日志及管理者的操作行为)进行分析后发现有任一rmc21或bmc22已处于异常状态，但尚未与管理系统3失去连线，则会认定这个rmc21或bmc22是处于所述第一类关注状态(步骤s34)。当发现任一rmc21、bmc22处于第一类关注状态时，管理系统3可自动对处于第一类关注状态的rmc21、bmc22实施远端恢复机制，以远程解除rmc21或bmc22的异常状态(步骤s37)。若管理系统3依据上述数据(主要依据rmc21与bmc22状态数据)进行分析后发现有任一rmc21或bmc22与管理系统3的连线正常，但判断可能即将出现异常状态，则会认定这个rmc21或bmc22是处于所述第二类关注状态(步骤s35)。当发现任一rmc21、bmc22处于第二类关注状态时，管理系统3可自动对处于第二类关注状态的rmc21、bmc22实施远端服务重启机制，以远程避免rmc21或bmc22进入可能的异常状态(步骤s38)。若管理系统3依据上述数据(主要依据状态数据、管理者的操作行为以及各项反馈信息)进行分析后发现有任一bmc22已失去了网络连线(即，管理系统3无法远程直接访问这个bmc22)，则会认定这个bmc22是处于所述第三类关注状态(步骤s36)。当发现任一bmc22处于第三类关注状态时，管理系统3可自动对处于第三类关注状态的bmc22实施远端救援机制，以远程排除bmc22失去连线的状态，并且使bmc22的网络连线恢复正常(步骤s39)。下面段落讨论所述第一类关注状态。由于部分的rmc21/bmc22不具备基本输入输出系统(basicinput/outputsystem,bios)，因此需要通过外部服务器所提供的网络时间协定(networktimeprotocol,ntp)服务，或是硬件时钟芯片提供的实时时钟(real-timeclock,rtc)服务来设定时间，以与其他设备达到时间同步。如上所述，若在rmc21或bmc22的时间同步程序尚未完成前发生了系统事件，则虽然该系统事件仍然会被记录在rmc21、bmc22的事件日志中，但该系统事件的时间栏位将无法记录正确的事件发生时间，而只会记录例如“pre-init”的字样。若没有正确的事件发生时间，则管理者无法将事件日志做为所述系统事件的参考指标，这样将会导致判断错误。除此之外，若所述rmc21、bmc22需要进行重置(reset)作业，也可能会造成上述系统事件的事件发生时间记录错误或异常的情况。参阅图5，为本发明的第一类关注状态排除流程图的第一具体实施例。本实施例中，所述管理系统3会定时存取数据库31(步骤s41)，以由数据库31中取得机柜2内的rmc21及bmc22的状态数据及事件日志，并且判断rmc21及bmc22的状态变化(步骤s42)。本实施例中，管理系统3主要是判断所获得的事件日志中，是否有任一系统事件的事件发生时间不明或错误(步骤s43)。若所述事件日志中的所有系统事件皆记录了正确的事件发生时间，则管理系统3不主动实施任何动作。若经分析后，管理系统3发现任一rmc21或bmc22具有时间不明或错误的系统事件，则管理系统3会将该rmc21或bmc22视为处于所述第一类关注状态(步骤s44)，即，认定这个rmc21或bmc22处于异常状态，但尚未失去网络连线。于一实施例中，管理系统3主要可于所述事件日志中的任一系统事件的事件发生时间被记录为“pre-init”或类似字样时(即，无法正确说明系统事件的发生时间)，判断所述系统事件的事件发生时间不明或错误。于另一实施例中，管理系统3主要可以在从事件日志中发现任一rmc21或bmc22具有事件发生时间不明的系统事件，并且从状态数据中发现这个rmc21或bmc22尚未完成时间同步程序或是需要进行重置作业时，判断所述系统事件的事件发生时间不明或错误。当管理系统3于步骤s44中认定一个rmc21或bmc22处于第一类关注状态后，管理系统3首先取得本次存取事件日志的时间戳记(步骤s45)，将这个时间戳记做为所述系统事件的备位时间识别信息，并储存于数据库31中(步骤s46)。于一实施例中，管理系统3是将本次存取数据库31以读取所述事件日志的时间做为上述时间戳记。于另一实施例中，管理系统3是将本次远程访问机柜2并从rmc21、bmc22取得所述事件日志的时间做为上述时间戳记，但不加以限定。举例来说，所述事件日志的原始内容可例如下表所示：系统事件事件发生时间事件一22.12.2018/23:30:18事件二pre-init0000000033事件三22.12.2018/23:3:20若管理系统3在2018年12月22日的下午11时32分23秒时存取了所述事件日志，并发现事件二的事件发生时间有误，则管理系统3可以主动为事件二产生所述备位时间识别信息，并且修改事件日志的内容或是产生新的事件日志。新的事件日志可例如下表所示：系统事件事件发生时间备位时间事件一22.12.2018/23:30:18x事件二pre-init000000003322.12.2018/23:32:23事件三22.12.2018/23:33:20x当管理者通过所述操作界面登入管理系统3，并且于管理系统3中查询所述事件日志时，管理系统3即可如上表所示，显示所述备位时间识别信息以做为事件二的事件发生时间。如此一来，即使rmc21或bmc22在时间同步未完成前发生一个系统事件，管理系统3仍可为该系统事件设定一个可供识别的备位时间，以利管理系统3以及管理者于对该系统事件的解读，并藉此强化远端恢复的效果。步骤s46后，管理系统3可进一步通过网络发出控制指令(例如第一控制指令)至处于第一类关注状态的rmc21或bmc22，以对具有时间错误的异常状态的rmc21或bmc22执行时间校正程序(步骤s47)。于一实施例中，所述时间校正程序是控制rmc21或bmc22藉由ntp服务进行时间校正。于另一实施例中，所述时间校正程序是强制rmc21或bmc22进行重置作业，但不加以限定。下面段落继续说明其他可能发生的第一类关注状态。由于数据中心1内部的机柜2数量众多，当管理者有更新的需求时，实难以通过人工方式逐台进行更新。因此，当管理者要对机柜2内的rmc21、bmc22实施更新作业时(例如固件更新)，可对管理系统3进行操作，以通过管理系统3的相关程序码来发送更新指令以及最新版本的固件，藉此于远端同时更新数据中心1内的多个机柜2的rmc21及bmc22。若于更新过程中遇到网络拥塞或网络信号不稳定造成网络连线中断等问题，使得部分rmc21、bmc22无法依循正常的更新流程完成更新作业，就有可能造成更新作业失败。然而，部分rmc21、bmc22在更新作业失败后仅会造成系统无法正常运作，但并未失去网络连线(例如进入更新模式后无法恢复为工作模式)，此时就需要由管理系统3于远端介入以进行异常状况排除。参阅图6，为本发明的第一类关注状态排除流程图的第二具体实施例。本实施例中，管理系统3同样定时存取数据库31(步骤s51)，以由数据库31中取得机柜2内的rmc21及bmc22的状态数据及事件日志，同时取得管理者通过操作界面所实施的操作行为，并且判断rmc21及bmc22的状态变化(步骤s52)。本实施例中，管理系统3首先可对rmc21及bmc22的状态数据以及事件日志进行分析，以判断是否有任一rmc21、bmc22的更新作业已逾时或发生错误(步骤s54)，并且判断所述更新作业逾时或发生错误的rmc21或bmc22的网络连线是否正常(步骤s55)。若管理系统3在分析后发现有任一rmc21或bmc22的更新作业逾时或发生错误但网络连线仍然正常，则可将这个rmc21或bmc22视为处于所述第一类关注状态(步骤s56)，即，处于异常状态，但尚未失去连线。更具体地，于上述步骤s52后，管理系统3可先依据所述操作行为来判断管理者是否曾对机柜2中的rmc21及/或bmc22实施了更新作业(步骤s53)。并且，于确定了管理者曾经实施了更新作业后，管理系统3再接续执行步骤s54以及步骤s55，以判断这些rmc21、bmc22的更新作业是否逾时或发生错误，以及网络连线是否正常。所述rmc21、bmc22在接受了管理者实施的更新作业后，将会自动进入更新模式。此时，rmc21、bmc22会在状态数据中设定已进入更新模式的标记(flag)。当周边设备与rmc21、bmc22沟通并且读到更新模式的标记时，就会自动停止与这个rmc21、bmc22的互动。因此，只要rmc21、bmc22更新作业失败而无法离开更新模式，这个rmc21、bmc22就无法正常运作。当管理系统3发现任一rmc21、bmc22接受了更新作业、更新作业已逾时或发生错误、但是尚未失去网络连线时，就可认定这个rmc21、bmc22处于所述第一关注状态。步骤s56后，管理系统3可进一步通过网络发出控制指令(例如第二控制指令)至处于第一类关注状态的rmc21或bmc22，以强制更新作业失败的rmc21或bmc22离开所述更新模式(步骤s57)。如上所述，在本实施例所指的更新作业失败情况下(即，无法离开更新模式)，所述rmc21、bmc22仍可接收并处理相关的指令，只是周边设备在读到更新模式的标记(flag)时就会自动停止与rmc21、bmc22的互动。本实施例中，管理系统3已判断所述rmc21、bmc22发生异常状态，因此会无视于上述标记，而藉由控制指令的发出来强制rmc21、bmc22离开更新模式。步骤s57后，管理系统3还可进一步通过网络发出另一控制指令(例如第三控制指令)至已离开更新模式的rmc21或bmc22，以强制rmc21或bmc22进行重置作业，或是再次实施所述更新作业(步骤s58)。藉此，管理系统3可以确保rmc21、bmc22已恢复正常运作，并且固件或软件处于更新完成的最新版本。下面段落接着讨论所述第二类关注状态。本发明中的rmc21、bmc22为一种嵌入式系统(embbededsystem)，因此即使机柜2内的端点服务器220未开机，管理系统3仍可藉由与rmc21、bmc22的沟通来实现远程开机、远程关机、查看设备状态等远程管理功能。一般来说，管理者在实施远程管理程序时，可在管理系统3上使用智能平台管理界面(intelligentplatformmanagementinterface,ipmi)工具程序来通过网络发送ipmi指令，藉此与机柜2内的rmc21、bmc22沟通。于使用ipmi工具程序的情况下，每一道ipmi指令的发送都需与目的地的rmc21、bmc22建立一个ipmi会话期间(session)，藉此才能与目的地的rmc21、bmc22进行沟通。具体地，在ipmisession建立完成后，管理系统3才能通过网络与rmc21、bmc22以及机柜2、端点服务器220的底层硬件设备沟通，进而取得所述指令的执行结果(例如取得固件版本、端点服务器220内的所有感测器的感测数值等)。惟，嵌入式系统本身的运算资源是相当有限的，除了运作所需的基本资源消耗外，与rmc21的沟通、与bmc22的沟通以及回复数据中心1内的各式监控系统等动作皆会进一步消耗嵌入式系统的运算资源。再者，当管理者通过管理系统3对各个rmc21、bmc22实施远端管理程序时，也需消耗rmc21、bmc22的运算资源，最明显的就是令rmc21、bmc22的ipmisession数量大幅增加，使得rmc21、bmc22出现回应不及或是请求超时(timeout)的现象。此时，虽然所述rmc21、bmc22尚未发生异常状态，但可能需要由管理系统3于远端介入以避免rmc21、bmc22将来发生异常状态而影响机柜2的运作。参阅图7，为本发明的第二类关注状态排除流程图的第一具体实施例。本实施例中，所述管理系统3同样会定时存取数据库31(步骤s61)，以由数据库31中取得机柜2内的rmc21及bmc22的状态数据，并且判断rmc21及bmc22的状态变化(步骤s62)。于一实施例中，管理系统3在步骤s62中主要是取得rmc21及各个bmc22目前的ipmisession总数。于另一实施例中，管理系统3在步骤s62中同时取得rmc21及各个bmc22目前的系统资源使用率。步骤s63后，管理系统3判断是否有任一rmc21、bmc22的ipmisession总数高于第一门槛值(步骤s63)，并且于任一rmc21、bmc22的ipmisession总数高于第一门槛值时，认定这个rmc21、bmc22处于所述第二关注状态(步骤s65)，即，rmc21或bmc22的连线正常，但判断可能即将出现异常状态。值得一提的是，若管理系统3于步骤s62中同时取得了rmc21及各个bmc22的系统资源使用率，则管理系统3可同时判断是否有任一rmc21、bmc22的系统资源使用率高于第二门槛值(步骤s64)。于此情境下，管理系统3会认定目前的ipmisession总数高于第一门槛值，并且系统资源使用率高于第二门槛值的rmc21或bmc22处于所述第二关注状态。于一实施例中，所述系统资源使用率为rmc21、bmc22的中央处理单元或记忆体的使用率。于另一实施例中，所述系统资源使用率为rmc21、bmc22内部主要用来提供各项服务(如超文本传输协议(hypertexttransferprotocol,http)服务或ipmi服务等)所使用的系统资源的使用率，但不加以限定。当管理系统3认定一个rmc21或bmc22处于第二类关注状态后，管理系统3可进一步通过网络发出控制指令(例如第四控制指令)至处于第二类关注状态的rmc21或bmc22，以令所述rmc21或bmc22重启ipmi服务(步骤s66)。藉此，rmc21、bmc22可将目前累积的ipmisession清空，以避免异常状态的发生。于一实施例中，所述第四控制指令为重置指令，管理系统3是通过网络发出重置指令至处于第二类关注状态的rmc21或bmc22，以强制rmc21或bmc22进行重置作业。如此一来，重置后的rmc21、bmc22即可直接重启ipmi服务。惟，上述仅为本发明的其中一个具体实施例，但不以上述为限。通过上述技术方案，管理系统3可以经由分析提早发现rmc21或bmc22可能即将发生异常状态，因此可主动于远端实施服务重启机制，以避免rmc21或bmc22真的发生异常状态而影响机柜2的运作。下面段落接着讨论所述第三类关注状态。如前文中所述，本发明的管理系统3主要是通过网络与数据中心1内的机柜2中的rmc21、bmc22进行沟通，并且管理者也是通过网络对这些rmc21、bmc22实施远程管理程序。因此，当机柜2中的bmc22失去网络连线时，管理系统3将无法与bmc22进行沟通，管理者也无法对bmc22进行管理。于本实施例中，bmc22失去网络连线的异常状况，可能是因为ip地址设定错误所引起的。一般来说，机柜2内的bmc22可能被设定成使用动态ip地址(即，bmc22的网络模式被设定为动态ip模式)或静态ip地址(即，bmc22的网络模式被设定为静态ip模式)。若bmc22的网络模式为动态ip模式，则可由数据中心1内的动态主机设定协定(dynamichostconfigurationprotocol,dhcp)服务器(图未标示)来主动配发一组动态ip地址给bmc22使用。若bmc22的网络模式为静态ip模式，则管理者可通过管理系统3的操作界面来自行为bmc22设定一组静态ip地址。要对bmc22实施网络设定作业以设定一组可用的静态ip地址，管理者需经由管理系统3下达至少四道指令给bmc22(即，需建立四个ipmisession)，包括：(1)设定bmc22的网络模式为静态ip模式；(2)设定静态ip地址；(3)设定子网络遮罩(netmask)；(4)设定闸道器(gateway)ip地址。如上所述，若管理者设定的静态ip地址错误(例如与dhcp服务器所配发的多组动态ip地址的其中之一重复)，或是闸道器ip地址设定错误，则在多个子网域共存的环境，或是需要通过闸道器才能沟通的环境下，所述bmc22将无法与管理系统3连线。对于管理系统3来说，虽然这个bmc22所属的端点服务器220仍然存在，但因为管理系统3失去了与这个bmc22间的连线，因此将无法对这个bmc22(及其所属的端点服务器220)进行管理。此时，管理系统3可能需要于远端介入以令bmc22恢复网络连线。参阅图8，为本发明的第三类关注状态排除流程图的第一具体实施例。本实施例中，所述管理系统3会定时存取数据库31(步骤s71)，以由数据库31中取得机柜2内的各个bmc22的状态数据、管理者通过管理系统3实施的操作行为、以及管理系统3基于所述操作行为所获得的各项反馈信息，并且判断bmc22的状态变化(步骤s72)。于一实施例中，管理系统3在步骤s72中取得的状态数据至少包括各个bmc22的网络模式(静态ip模式或动态ip模式)、目前使用的静态ip地址、子网络遮罩及闸道器ip地址等，不加以限定。并且，管理系统3在步骤s72中取得的反馈信息主要包括所述操作行为实施时，管理系统3、机柜2及各个端点服务器220(以及各个bmc22)基于这个操作行为所产生的反馈、系统参数及执行数据等数据，但不加以限定。步骤s72后，管理系统3首先依据所述状态数据以及反馈信息判断机柜2中是否有任一bmc22失去了与管理系统3间的连线(步骤s73)，并且，依据所述操作行为判断管理者是否刚刚为机柜2中的任一bmc22实施了网络设定作业(步骤s74)。若经分析后发现管理者刚刚对某一bmc22实施了网络设定作业，并且这个bmc22在网络设定作业后即失去连线，则管理系统3即可将这个bmc22视为处于所述第三类关注状态(步骤s75)，即，bmc22已失去连线。值得一提的是，于前述步骤s73中，管理系统3主要可于任一bmc22的网络模式被设定为静态ip模式，并且这个bmc22的静态ip地址与dhcp服务器所配发的多组动态ip地址的其中之一重复时，判断这个bmc22失去网络连线(已经失去连线，或可能失去连线)。另，于前述步骤s73中，管理系统3还可于任一bmc22的网络模式被设定为静态ip模式，并且这个bmc22的闸道器ip地址设定错误时，判断这个bmc22失去网络连线(已经失去连线，或可能失去连线)。惟，上述仅为本发明的部分具体实施范例，但不应以上述为限。于步骤s75后，管理系统3已可认定某一bmc22处于所述第三类关注状态，接着，管理系统3判断在数据中心1中主要负责这个bmc22的rmc21为何(步骤s76)，并且控制这个rmc21通过机柜2的内部硬件线路24检查所述bmc22所属的端点服务器220(步骤s77)，以确认这个端点服务器220是否存在(步骤s78)。如图2所示，一个机柜2内的rmc21主要可通过内部硬件线路24实体连接机柜2中的所有端点服务器220中的bmc22，因此，即使bmc22失去网络连线，同一个机柜2内的rmc21仍可通过内部硬件线路24来与bmc22进行沟通。若于上述步骤s78中判断所述端点服务器220不存在(例如已被抽离机柜2，或已经损坏)，则管理系统3对应发出警示信号(步骤s79)。于一实施例中，管理系统3可通过操作界面发出警示信号(例如文字、灯光或声响)，以对管理者进行警示。于另一实施例中，管理系统3可通过网络发送警示信号(例如简讯、电子邮件或通讯软件)给管理者，以达到警示作用。若于上述步骤s78中判断所述端点服务器220仍然存在，则管理系统3控制所述rmc21通过内部硬件线路24发送一组ipmi指令至所述bmc22，以令bmc22恢复网络连线(步骤s80)。于一实施例中，管理系统3可通过rmc21将ipmi指令发送至所述bmc22，以重新设定所述bmc22的静态ip地址，或是重新设定所述bmc22的闸道器ip地址，藉此令bmc22恢复与管理系统3间的连线。通过上述技术方案，管理系统3可以在bmc22失去连线后主动于远端对bmc22实施救援机制，以令bmc22恢复网络连线。本发明的方法可由管理系统3自动搜集所需信息并对所有rmc21及bmc22的状态进行分析，同时于任一rmc21、bmc22处于多种关注状态之一时自动实施对应机制以排除异常状态。如此一来，本发明的技术方案可大幅降低管理成本，亦使得数据中心1的监控无需人为干涉，也不受距离与时间的影响。当然，本发明还可有其它多种实施例，在不背离本发明精神及其实质的情况下，熟悉本领域的技术人员当可根据本发明作出各种相应的改变和变形，但这些相应的改变和变形都应属于本发明所附的权利要求的保护范围。当前第1页12