CN1851661A - 一种面向大规模计算系统的高可信日志系统实现方法 - Google Patents

Abstract

一种用于大规模计算部件环境的高可信轻量级日志管理方法，包括以下步骤：每个受日志监测部件管理的计算部件，当有日志消息产生时，为该消息自动生成一个在所有计算部件中全局唯一的编码；每个计算部件将日志消息与所产生的日志消息全局唯一编码一起保存在生成该消息的计算部件本地的受保护的存储区域内；待系统处于稳定性较高的时段，由计算部件向日志监测部件传输已编码的日志消息；日志监测部件将接收到的已编码的日志消息保存到日志监测部件本身的受保护存储区域内；日志监测部件向发送日志消息的计算部件发送消息收到的确认信息；日志监测部件等待系统处于可靠性较高的时机，向日志缺失的计算部件发起请求，让其重新传输缺失的日志信息。

Description

一种面向大规模计算系统的高可信日志系统实现方法

技术领域

本发明涉及多部件计算系统的日志系统实现方法，特别是被监测的计算部件数量大，或者日志传输可信性要求高的轻量级日志实现方法。

背景技术

日志，是计算系统运行过程中，由开发人员预先编写消息内容，并通过一致的使用接口，保存在本地和/或远程存储介质的数据和信息。它是了解系统运行时状况的重要依据，也是系统出现故障时，分析和解决问题的重要手段。

计算系统，是指各种具有一定逻辑运算能力和暂时/永久保存信息能力的计算部件，根据实际需要，通过有数据通信能力的连接方式组合和/或叠加，构成的系统。

当前的日志系统通常采用如下的过程：

1.  计算部件通过标准的消息处理接口，先将产生的消息暂存于易失的存储区域中(如RING BUFFER机制中)，然后，在某种事件的驱动下，将消息保存到系统本地的永久性介质上。

2.  在某种事件的驱动下，将消息通过某种数据传输网络，传输到全局日志监测部件，并在监测部件上实现异于消息发生地的永久存储。

现有方法，最初源于UNIX系统的SYSLOG系统，并在WINDOWS系统，通信交换系统，互联网服务系统，无线通信系统，存储系统中得到广泛的应用。本专利主要面向被监测对象数量巨大(如超过目前部件数最多，峰值运算能力最高的超级计算机系统)，对日志传输的可信性要求高，和/或需用准确的日志信息来分析和解决部件故障的各种计算系统。如，大量交换设备的通信运营系统，大量专用无线终端客户的无线通信系统、大规模网络服务系统、以及大规模存储服务系统。

在当今的大规模计算系统中，部件数量急剧上升，例如，IBMBlueGene-L的部件数成千上万，下一代千万亿次超级计算机的部件数更是将要急剧地增加。VIP无线服务、大规模存储服务、大规模网络服务等系统中的计算部件(分别称为手持终端、存储设备和服务器)，也都呈现日益增长的势头。面对这样大量的计算部件，故障的有效可信监测，就显得尤为重要。

然而，当前的日志系统，在应用于大规模，高可信计算系统方面，在出现故障和异常时，却表现出明显的盲区。具体情况是，部件正常时，大量日志信息能够连续地记录下来；而部件发生故障，尤其是系统级(非应用级)故障时，故障之前，之中，之后的关键性日志，丢失或不足的情况却相当严重。不仅计算部件本地的日志存在丢失现象，发送到日志监测部件上的关键日志更是经常出现缺失。曙光超级计算系统的实践证明，在全局监测日志的环境中，如果在很短时间内发生400个以上的部件故障，则有200次左右的故障日志会无法监测到。再比如，全局监测日志与各个部件实际产生的日志是否一致、是否正确，这一问题严重影响到计算系统管理和使用的方便性，然而，在目前的系统实现和专利文献中，尚没有日志一致性、正确性的保证机制。还有，部件故障日志在发生故障的部件本地进行存储，这一过程也常常是不可信的，系统管理使用人员和开发人员讨论过程中也经常发现，出现故障时，部件本地和远程日志中都没有可供分析故障原因的信息，而开发人员则认为，相关信息肯定应该已经记录到本地存储介质上了，并且在某些情况下能够看到这些信息。

在与日志有关的可信性方面，CN02823231.3提出了一种共享日志，并保证日志正确写入的方法。然而，该专利的目标在于通过日志辅助实现存储事务的原子性，而并非通过可信日志检验系统的故障。而且，对于大规模计算系统，成千上万的部件同时共享存储和日志的情况是难以想象的。

这一切说明，以往的日志系统，对少量部件环境中研究开发的较多，对辅助其他功能的实现关注较多，而基本忽略了大规模计算环境下的日志系统本身的可信性(Dependability)需求。随着大规模集成电路的发展和计算单元计算能力的大幅度提高，单部件正常工作时的处理和存储能力已经不是系统生产效率的瓶颈。而大规模计算环境下的单个/多个部件失效，则成为影响大规模应用效能的一个重要因素。日志作为监测系统故障的重要机制，在大规模系统下的可信性亟待提高。

发明内容

本发明需要解决的技术问题是，提出了面向大规模计算部件环境的，高可信的，轻量级的日志系统实现方法。使用本发明所描述的方法，可以在大规模计算环境中，实现对系统日志的可信的，轻量级的监测。

本发明提出了一种用于大规模计算部件环境的高可信轻量级日志管理方法，包括以下步骤：

1.每个受日志监测部件管理的计算部件，当有日志消息产生时，为该消息自动生成一个在所有计算部件中全局唯一的编码；

2.每个计算部件将日志消息与上述产生的日志消息全局唯一编码一起保存在生成该消息的计算部件本地的受保护的存储区域内；

3.待系统处于稳定性较高的时段，由计算部件向日志监测部件传输已编码的日志消息；

4.日志监测部件将接收到的已编码的日志消息保存到日志监测部件本身的受保护存储区域内；

5.日志监测部件向发送日志消息的计算部件发送消息收到的确认信息；

6.日志监测部件等待系统处于可靠性较高的时机，向日志缺失的计算部件发起请求，让其重新传输缺失的日志信息。

上述步骤3和5一起构成的发送和确认过程称为两阶段握手发送。上述步骤6称为非主动重传。

优选地，本发明还包括如下系统稳定性判断方法：

计算部件出现故障并恢复之后，可以认为其处于稳定性较高的时刻，此时计算部件可主动进行重新传输；

当计算部件没有接收到日志监测部件发送的确认信息时，可认为系统处于不稳定状态，可延长传输定时器；

当日志监测部件发现某个计算部件在传送日志信息时，可认为目前该计算部件及两者间的链接处于稳定状态，可向该计算部件请求传送其缺失的日志。

优选地，日志监测部件请求重传缺失日志信息的步骤包括：间隔预定时间，在日志监测部件的I/O利用率低于预定值的时刻，由日志监测部件发起主动请求；在日志监测部件本地永久保存的日志信息中，检索到最老的缺失日志编码；从此编码开始，向后检索，获得所有缺失的日志号；在网络占用率低于预定值，日志监测部件最近接收到所选定的计算部件发来的日志，而且所接收到的日志数量小于预定值的情况下，将所获得的缺失日志的日志号传输给所选定的计算部件。

附图说明

下面将参照附图，对本发明的优选实施例进行详细的描述，其中：

图1是适合于本发明实施方式的大规模计算系统框图。

图2是依照本发明实施方式的一种日志编码方式实例。

图3是依照本发明实施方式的一种实现受保护的易失存储区域的过程实例。

图4A～4C是为实现全局唯一编码，每个计算部件将本部件事件流水号、和日志内容+编码放入受保护存储区域，以及永久存储区域的实例。

图5是示出了本发明的日志管理方法的主要步骤的流程图。

图6A～6C是依照本发明实施方式，由某个计算部件和日志监测部件之间，进行二次握手与非主动重试传输的过程实例。

图7是依照本发明的实施方式，日志监测部件发起轻量级的主动请求和某个计算部件进行本地检索的过程实例。

具体实施方式

下面结合附图说明本发明的具体实施方式。应该指出，所描述的实施例仅是为了说明的目的，而不是对本发明范围的限制。所描述的各种数值并非用于限定本发明，这些数值可以根据本领域普通技术人员的需要进行任何适当的修改。

(系统描述)

本发明适用于所有符合图1结构的大规模计算系统。参考数字10至13表示产生日志的计算部件。大规模计算系统中，这些部件数量巨大(数以千计)。参考数字19表示日志监测部件。参考数字18表示用于传输日志的网络，可以是任何基于数据包的传输网络。所有的计算部件，都能通过该网络，利用其自带的网络层传输协议，直接或间接访问到日志监测部件，而日志监测部件也能利用自身的网络层传输协议，直接或间接访问到每一个计算部件。

(方法描述)

图5是示出了本发明的日志管理方法的主要步骤的流程图，其中：

在步骤001，每个在日志监测部件管理之下的计算部件，当其中有日志消息产生时，根据系统的实际情况，按照事先约定的统一规则，为该条消息自动生成一个在所有计算部件中全局唯一的编码。

在步骤002，这些计算部件将日志消息与上述产生的日志消息全局唯一编码一起保存在生成该消息的计算部件本地的受保护的存储区域内。

接着，计算部件判断系统是否处于稳定状态(步骤003)，如果是，则计算部件向日志监测部件传输日志信息(步骤004)。

日志监测部件接收到日志信息之后，立即保存到日志监测部件本身的受保护存储区域内(步骤005)。

日志监测部件向发送日志消息的计算部件发送消息收到的确认信息(步骤006)。至此，两阶段握手发送过程结束。

日志监测部件判断系统是否处于可靠性较高的阶段(步骤007)，如果是，则向日志缺失的那些计算部件请求，让其重新传输缺失的日志信息(步骤008)。此步骤即为非主动重传。

如图2所示，参考数字20表示一个已经生成的全局唯一日志编码。日志的全局唯一数字编码可以实现为：计算部件号+精确时间戳+发生事件的部位编号+本部件事件流水号。采用数字编码可以在计算部件数量激增时，依旧不占用过大的存储区域。这种编码方式保证了消息的唯一确定性和连续性，可以在故障发生时，精确定位和区分故障起源及其传播过程中影响到的所有部位，克服了以往方法定位过粗，粒度过大，不利于故障分析的缺点。

参考图3和图4，生成编码的步骤如下：

a)从受保护存储区(301)中，获取本部件事件当前流水号(4001)；

b)将本部件事件流水号增加1，再保存回受保护存储区域中；

c)获取精确时间戳(202，4005，4011，4105，4111)，时间戳数据较长，因此单独占据一个机器字；

d)获取本计算部件号(201，4004，4010，4104，4110)；

e)获取发生事件的部位号，和本计算部件号一起占据一个机器字(203，4003，4009，4103，4109)；

f)将上述数据组合在一起，构成当前事件在整个大规模计算系统中的唯一编码。

图3展示了受保护的存储区域的一种实现。可能对受保护区域造成破坏的有两种情况：系统初始化时的清空操作(304)，以及正常使用期间的误访问(303)。图3中，对受保护的存储区域(301)访问之前，都要先对受保护存储区域表(302)进行检查，使日志内容在故障时不会遗失。301中阴影部分代表受保护的易失存储区域。保护的方法，根据具体情况的不同，既可以按照图3，实现故障时和重启时对易失存储区域的保护，也可以直接存储到非易失存储区域中，如磁盘等。

图4A显示的是编号为1002的计算部件(4004，4010)将本部件流水号(4001)和两条日志消息保存在受保护的存储区域中的情况实例。图中表格从下到上表示存储区域偏移地址从0开始递增。把本部件流水号(4001)放在受保护存储区域偏移地址为0的地方，因为每生成一条新日志消息都要原子地增加这个量，存取频率很高，因此固定地址有利于提高访问速度。图中显示的是日志信息在受保护存储区域内线性顺序存储的情况，结合指针的变换和日志信息的移位，则完全等价于目前为广泛采用的环形缓冲区技术。

图4A中从下向上第一条日志信息是一条尚未发送(4007)的日志。该日志由部件333发出(4003)，故障内容为内存位错(4008)，发生的精确时戳是1234567890123450(4005)，在该计算部件中的流水号为65501(4006)。

图4A中从下向上第二条日志信息是一条已发送但未确认(4013)的日志。该日志由部件116发出(4009)，故障内容为IO设备故障(4014)，发生的精确时戳是1234567890123000(4011)，在该计算部件中的流水号为65500(4012)。

图4A中，参考数字4002是最新尚未发送的日志指针，指向65501。

图4B显示的是计算部件将已经发送的日志保存到永久存储区域中的实例。为了实现轻量级的主动和被动发送，计算部件向日志监测部件发送完受保护存储区域内的日志消息之后，直接将这些消息保存到本地的永久存储区域中。

图4B中从下向上第一条日志信息是一条已发送未确认(4107)的日志。该日志由部件45发出(4103)，故障内容为网络故障(4108)，发生的精确时戳是1234567890000000(4105)，在该计算部件中的流水号为65123(4106)。

图4B中从下向上第二条日志信息是一条已确认(4113)的日志。该日志由部件116发出(4109)，故障内容为IO设备故障(4114)，发生的精确时戳是1234567883456000(4111)，在该计算部件中的流水号为65122(4112)。

图4B中4101是未确认的最老日志指针，指向65123。

图4C是日志监测部件接收到计算部件1002的日志信息的情况。图中从下向上第一条记录，是日志监测部件接收到的，图4A中从下向上第二条记录。图4C中从下向上第二条记录，是日志监测部件接收到的，图4B中从下向上第二条记录。

图4A中从下向上第一条记录是计算部件未发送的日志信息，因此图4C中没有相应记录。图4B中从下向上第一条记录，是计算部件已发送，但因为故障或某种情况，导致日志监测部件没有接收到的情况。因此，最老不连续日志指针(4201)的值指向65123。

图6A、图6B、图6C显示了日志计算部件依照两次握手和非主动重试原则，向日志监测部件主动发送，以及日志监测部件被动接收的过程。此三图中带阴影的部分是日志监测部件的行为，其余则属于计算部件。

图6A和图6B中，主动发送的发起可能分三种情况，第一，得到了日志监测部件的主动请求，然后主动将所请求的日志重新提取到受保护存储区域内(步骤521、522、523)。第二，计算部件故障恢复之后，如重新启动等，这时，由于故障之前可能有很多日志在未确认的情况下已经存入永久存储区，因此需要先将这些日志重新复制到受保护存储区域(步骤531、532、523)。第三，计算部件正常运行过程中，定时主动发送(步骤511、512、513)。不论主动发送过程时由何种情况发起的，当这一轮发送结束之后，都会重新启动日志发送定时器。

两次握手指计算部件的发送和监测部件的响应，两次握手和轻量级的主动发送结合既避免了消息丢失，又尽可能减少了网络占用率。可信传输多采用三次握手协议，日志传输一般采用无握手的不可信传输方式，而两次握手只适合可信地日志传输。

非主动重试的含义是，计算部件发送日志信息之后，只需等待监测部件“接收到”的反馈(步骤552)，对于未得到监测部件相应的日志消息，计算部件不会立刻主动反复尝试重发，非主动重试适用于出现故障时消息可能丢失的情况，可降低网络占用率，避免因反复传输日志导致的故障雪崩和网络拥塞。

当发送过程开始后，计算部件先将保护存储区中所有的未发送日志打上已发送未确认标记，并一起发送给日志监测部件(步骤541)。这一步操作应该是原子的。此后，计算部件只需等待日志监测部件的响应(步骤542)。如果得到响应，则根据响应中日志发送部件确认收到的日志，将保存在易失存储区域中的日志打上已确认标记。如果超时，没有得到响应，就将所有已发送未确认的日志一起保存在受保护存储区域中(步骤543)。

当计算部件发现，在一轮发送过程中，有些日志信息没有得到日志监测部件的确认时(步骤561)，就认为系统的某些部位处于故障状态，因此，发送定时器将定时间隔加倍，直到设定的最大值为止(步骤562)。

当计算部件发现，在一轮发送过程中，所有的日志信息都得到日志监测部件的确认时，就认为系统处于无故障状态，因此，发送定时器将定时间隔减半，直到设定的最小值为止(步骤563)。

对于日志监测部件而言，如果工作正常的话，则一直处于监听状态(步骤551，552)。监听来自计算部件的日志消息。当日志监测部件接收到消息时，先对暂存到本地的受保护易失存储区(步骤553)，然后再向计算部件发送他收到的日志信息的全局唯一标识(步骤554)。上面这两步操作应该是原子的。最终，受保护易失存储区内的所有日志信息都应该保存在日志监测部件的本地永久存储区域中(步骤555)。

图7是描述日志监测部件发起轻量级主动请求的情况。日志监测部件主动发起请求，首先应该避免本地I/O量比较高的情况(步骤602)，其次，考虑到大规模计算系统的平均无故障时间一般都在小时级，可以每隔一段时间发起一次，这个时间可以和全部部件的平均无故障时间相同(步骤601)，这样，既避免了间隔过长丢失一些日志，也避免过多重复请求影响网络性能。当做出主动请求决定之后，首先在日志监测部件本地永久保存的日志信息中，检索到最老的缺失日志编码(步骤603)，然后，从这个编码开始，向后检索，获得所有缺失的日志号(步骤603)。

在向计算部件主动请求(步骤606)之前，还要判断，系统当前负载能否允许请求，以及作为请求对象的计算部件是否能够实现这些请求。判断的标准可以包括网络负载，最近收到的日志消息密度，以及最近计算部件是否存在故障。网络负载高时，显然不适合发起请求。网络负载低(比如说，带宽占用率低于60％)(步骤604)时，还要判断特定的计算部件是否适合发送日志请求。一般情况下，计算部件如果在正常运行状态，会缓慢地发出一些表示运行正常的日志信息。当计算部件长期不发送任何日志的时候，很可能是该部件已经处于无法接收请求的故障状态。从另一方面看，如果某计算部件在较短时间内发出大量的日志信息，则可能意味着该部件处在重负载中，如果计算部件发出大量表示出错的日志信息，也可能意味着该部件处在严重故障中(步骤605)。

最后所应说明的是：以上实施例仅仅用以说明而非限制本发明的技术方案，尽管参照上述实施例对本发明进行了详细说明，本领域的普通技术人员应当理解：依然可以对本发明进行修改或者等同替换，而不脱离本发明的精神和范围的任何修改或局部替换，其均应涵盖在本发明的权利要求范围当中。

Claims (5)

1.一种用于大规模计算部件环境的高可信轻量级日志管理方法，包括以下步骤：

每个受日志监测部件管理的计算部件，当有日志消息产生时，为该消息自动生成一个在所有计算部件中全局唯一的编码；

每个计算部件将日志消息与所产生的日志消息全局唯一编码一起保存在生成该消息的计算部件本地的受保护的存储区域内；

待系统处于稳定性较高的时段，由计算部件向日志监测部件传输已编码的日志消息；

日志监测部件将接收到的已编码的日志消息保存到日志监测部件本身的受保护存储区域内；

日志监测部件向发送日志消息的计算部件发送消息收到的确认信息；

日志监测部件等待系统处于可靠性较高的时机，向日志缺失的计算部件发起请求，让其重新传输缺失的日志信息。

2.根据权利要求1所述的日志管理方法，其特征在于在系统稳定性确定期间，如果计算部件出现故障并恢复，则认为其处于稳定性较高的时刻，此时计算部件主动进行重新传输。

3.根据权利要求1所述的日志管理方法，其特征在于在系统稳定性确定期间，当计算部件没有接收到日志监测部件发送的确认信息时，认为系统处于不稳定状态，延长传输定时器。

4.根据权利要求1所述的日志管理方法，其特征在于在系统稳定性确定期间，当日志监测部件发现某个计算部件在传送日志信息时，认为目前该计算部件及两者间的链接处于稳定状态，向该计算部件请求传送其缺失的日志。

5.根据权利要求1所述的日志管理方法，其特征在于日志监测部件请求重传缺失日志信息的步骤包括：

间隔预定时间，在日志监测部件的I/O利用率低于预定值的时刻，由日志监测部件发起主动请求；

在日志监测部件本地永久保存的日志信息中，检索到最老的缺失日志编码；

从此编码开始，向后检索，获得所有缺失的日志号；

在网络占用率低于预定值，日志监测部件最近接收到所选定的计算部件发来的日志，而且所接收到的日志数量小于预定值的情况下，将所获得的缺失日志的日志号传输给所选定的计算部件。

Images