异常处理方法及接口板与流程

本公开涉及通信技术领域，具体而言，涉及一种异常处理方法及接口板。

背景技术：

分布式设备，例如交换机设备，往往由各个不同功能的单板组成，常见的包括主控板、接口板等。接口板在工作过程中，当驱动进程发生异常时会生成一个用于记录异常发生时该驱动进程的实时状态信息的core文件，该core文件对于定位接口板的故障原因至关重要。

然而，core文件生成后大多存储在接口板的内存中，当驱动进程发生异常后，主控板与接口板会发生板间握手超时，从而将接口板重启，造成core文件丢失。同时，接口板的中央处理单元cpu需要在重启之前将core文件发送到全局主控板的cpu。但是，接口板的驱动进程异常会导致接口板的cpu通过驱动进程将core文件发送至接口板的转发芯片，使core文件无法由转发芯片间的通道被转发到全局主控板的cpu，进而无法通过接口板的core文件执行故障原因定位。

技术实现要素：

本公开的目的在于提供一种异常处理方法及接口板，以解决接口板的驱动进程发生异常时驱动进程的异常信息无法在接口板重启之前及时传递到主控板的问题。

为了实现上述目的，本公开实施例采用的技术方案如下：

第一方面，本公开提供一种异常处理方法，应用于分布式设备的接口板，所述方法包括：监控所述接口板的驱动进程；确定所述驱动进程异常，获取所述驱动进程的异常信息；生成携带所述异常信息的异常上报报文；生成接管ipc进程；通过所述接管ipc进程发送所述异常上报报文至所述接口板的ipc芯片；所述ipc芯片通过到达全局主控板的ipc芯片的ipc通道发送所述异常上报报文，以使所述全局主控板的ipc芯片将收到的所述异常上报报文发送至所述全局主控板的控制单元。

第二方面，本公开实施例还提供一种接口板，应用于分布式设备，所述接口板包括中央处理单元、一个以上存储器、进程间通信ipc芯片以及转发芯片；所述中央处理单元运行存储在所述一个以上存储器中的指令，以执行上述的异常处理方法中的各步骤。

第三方面，本公开实施例还提供一种分布式设备，包括一个以上接口板和全局主控板。其中，所述接口板包括中央处理单元、ipc芯片以及转发芯片；所述中央处理单元用于监控运行的驱动进程；确定所述驱动进程发生异常，生成携带所述异常信息的异常上报报文；生成接管ipc进程，通过所述接管ipc进程发送所述异常上报报文至所述全局主控板的ipc芯片。所述接口板的ipc芯片通过到达所述全局主控板的ipc芯片的ipc通道发送所述异常上报报文，所述全局主控板的ipc芯片用于将收到的所述异常上报报文发送至所述全局主控板的控制单元。

相对于现有技术而言，本公开具有以下有益效果：

本公开提供的异常处理方法及接口板，有效解决了接口板的驱动进程发生异常时驱动进程的异常信息无法在接口板重启之前及时传递到主控板的问题，避免了异常信息的core文件丢失，提高了接口板故障原因定位的可靠性。此外，本公开无需借助外部的存储装置(譬如flash存储器)，也不需要在接口板设置高端内存区存放core文件，避免了core文件对高端内存区的内存占用，并减少分布式设备的成本。

附图说明

为了更清楚地说明本公开实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本公开的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它相关的附图。

图1为本公开实施例提供的异常处理方法的流程示意图；

图2为接口板与全局主控板处于同一机框的应用场景示意图；

图3为接口板与全局主控板分别处于不同机框的应用场景示意图；

图4为本公开实施例提供的接口板的示意图。

具体实施方式

请参阅图1，为本公开实施例提供的异常处理方法的流程示意图，该异常处理方法应用于分布式设备中的接口板，接口板与全局主控板通信连接。下面对该异常处理方法介绍如下。

步骤s101，监控接口板的驱动进程；

步骤s102，确定驱动进程异常，获取驱动进程的异常信息；

步骤s103，生成携带异常信息的异常上报报文；

步骤s104，生成接管ipc进程；

步骤s105，通过接管ipc进程发送异常上报报文至接口板的ipc芯片；

步骤s106，接口板的ipc芯片通过到达全局主控板的ipc芯片的ipc通道发送所述异常上报报文，以使全局主控板的ipc芯片将收到的异常上报报文发送至全局主控板的控制单元。

通过上述对接口板驱动进程的异常处理方法，在驱动进程发生异常时会迅速启动一接管ipc进程，该接管ipc进程无需初始化sdk，可只包含原驱动进程的报文收发功能，用于接替驱动进程进行ipc报文的收发。因此，该接管ipc进程可以达到较快的启动速度。本实施例中，驱动进程的异常信息可以写入一个core文件中，并通过异常上报报文进行发送，异常上报报文为一种ipc报文。如此，可以及时将包括驱动进程的异常信息的core文件发送给全局主控板进行记录，用以定位驱动进程发生异常的接口板的故障原因，从而提高接口板故障原因定位的可靠性。此外，上述方案无需借助外部存储器(譬如flash存储器)，也不需要在接口板设置高端内存区存放core文件，避免设置高端内存区导致的高成本。

其中，全局主控板可以理解为当前正在控制接口板的主用主控板。通常来说，接口板可以与两个或以上的主控板通信，其中一个作为主用主控板，其它的则作为备用主控板以在发生主备倒换事件(例如主用主控板发生异常)时替代主用主控板对接口板进行控制。值得说明的是，接口板和全局主控板可以处于同一机框(同框)，也可以处于不同的机框(跨框)。

其中，分布式设备的系统核心数据会同步到所有单板(包括主控板和接口板)中。系统核心数据可包括通信系统的每个单板的单板信息、每个单板所在的分布式设备信息以及当前的全局主控板。由此，接口板可以根据系统核心数据判断是否与当前的全局主控板处于同一机框。

值得说明的是，在一些可能的情况下，同一接口板既可以与全局主控板处于同一机框，也可以与全局主控板处于不同机框。例如，假设某个接口板和其备用主控板在某一机框，当前的全局主控板处于另一机框，此时接口板与全局主控板则处于不同机框。当接口板发生主备倒换事件时，原备用主控版可以作为新的主用主控板以替代原主用主控板对接口板进行控制，主备倒换后，接口板与全局主控板又处于同一机框。

为了对本公开提供的上述异常处理方法进行进一步的详细描述，下面结合图2和图3，对接口板以及全局主控板分别处于分布式设备的同一机框以及不同机框时的情况进行示例性描述。

在一种可能的实施方式中，如图2所示，根据分布式设备的系统核心数据，若确定接口板和全局主控板都位于机框20，则接口板的cpu根据全局配置的系统核心数据中全局主控板的框号以及本板的框号可以确定与全局主控板是否处于同一机框。

再如图3所示，若确定接口板位于机框31，全局主控板位于机框32，则可判定接口板与全局主控板处于不同机框。此时，本公开所说的分布式设备可以包括机框31以及机框32。

首先，如图2所示，接口板210与全局主控板220处于同一机框20。接口板210包括中央处理单元211和与中央处理单元211连接的ipc芯片212。

全局主控板220包括控制单元221和与控制单元221连接的ipc芯片222，ipc芯片222与接口板210的ipc芯片212连接，用于实现全局主控板220和接口板210之间的ipc通信。

下面基于图2对接口板210与全局主控板220处于同一机框20时，上述异常处理方法的详细过程进行介绍。

中央处理单元211中运行的异常监控进程对驱动进程进行监控。详细地，异常监控进程可根据驱动进程的套接字号(socketnumber)，周期性地与驱动进程建立套接字测试连接。例如，可以根据驱动进程的套接字号，每隔t秒(如1秒、3秒、5秒等)与驱动进程建立套接字测试连接，如果检测到与驱动进程建立套接字测试连接成功，则再隔t秒继续与驱动进程建立套接字测试连接，通过这样的方式实现对驱动进程的实时监控。

异常监控进程一旦确定与驱动进程建立套接字测试连接失败，则可确定接口板210的驱动进程发生异常。在另一种方式中，在套接字测试连接失败时，中央处理单元生成携带异常信息的异常上报报文。详细地，驱动进程的实时状态信息(包括异常信息)会记录在一个core文件中，core文件存储在接口板210的内存中。然后，异常监控进程会从内存中查找core文件，生成携带core文件的异常上报报文(ipc报文)。另外，中央处理单元211可通过分布式设备的系统核心数据判定接口板210与全局主控板220处于同一机框20，同时从系统核心数据中获得全局主控板220的mac地址，并以全局主控板220的mac地址为目的mac地址，生成携带core文件的ipc报文作为所述异常上报报文。其中，异常上报报文的以太类型是ipc类型，其以太网头中包括源mac地址和目的mac地址，源mac地址为接口板210的mac地址(接口板210所在插槽(slot)对应的mac地址)，目的mac地址为全局主控板220的mac地址(全局主控板220所在插槽对应的mac地址)。

中央处理单元211生成接管ipc进程，将携带core文件的异常上报报文通过接管ipc进程发送到接口板210的ipc芯片212。详细地，ipc芯片212在接收到异常上报报文后，确定异常上报报文中的目的mac地址为全局主控板220的mac地址，并从异常上报报文的以太网头中获得全局主控板220的mac地址。然后，根据全局主控板220的mac地址，从转发表项中查找对应的出端口，并通过查找的对应的出端口发送异常上报报文，进而将异常上报报文发送到全局主控板220的ipc芯片222。

全局主控板的ipc芯片222收到异常上报报文，根据目的mac地址确定是本板的mac地址，将异常上报报文发送到本板的控制单元210进行记录。

如此，当驱动进程产生异常后，接口板210与全局主控板220之间建立通信时无法再调用驱动进程，此时接口板210的中央处理单元110立即启动一接管ipc进程，该接管ipc进程与驱动进程的套接字号相同，以临时接替驱动进程与全局主控板220建立ipc通信。这样即便驱动进程发生异常，也可以通过启动的ipc进程与全局主控板220建立ipc通信以进行core文件的及时发送。如此可避免因驱动进程异常，导致core文件无法由接口板210的转发芯片213与全局主控板220的转发芯片223之间的通道进行转发的问题。

此外，驱动进程异常后，全局主控板220与接口板210会发生板间握手超时，从而将接口板210重启，当接口板210重启完成之后，驱动进程仍可以使用原来的套接字号。

如图3所示，示出了出现驱动进程异常的接口板以及全局主控板分别位于不同机框的情况。例如，接口板处于机框31，全局主控板处于机框32。详细地，机框31包括接口板310，接口板310包括中央处理单元311、与中央处理单元311连接的ipc芯片312以及与ipc芯片312连接的转发芯片313。

机框32包括接口板320以及全局主控板330。接口板320包括转发芯片321和与转发芯片321连接的ipc芯片322。全局主控板330包括控制单元331和与控制单元331连接的ipc芯片332，ipc芯片332与接口板320的ipc芯片322连接，用于实现全局主控板330和接口板320之间的ipc通信。

下面基于图3，以接口板310为驱动进程发生异常的接口板为例，对接口板310与全局主控板330分别位于机框31和机框32时，上述异常处理方法的详细过程进行介绍。

中央处理单元311中运行的异常监控进程对驱动进程进行监控。详细地，异常监控进程可根据驱动进程的套接字号(socketnumber)，周期性地与驱动进程建立socket连接。例如，可以根据驱动进程的套接字号，每隔t秒(如1秒、3秒、5秒等)与驱动进程建立套接字测试连接，如果检测到与驱动进程建立套接字测试连接成功，则再隔t秒继续与驱动进程建立套接字测试连接，通过这样的方式实现对驱动进程的实时监控。

异常监控进程一旦确定与驱动进程建立套接字测试连接失败，则可确定接口板210的驱动进程发生异常。

中央处理单元311生成携带驱动进程异常信息的异常上报报文。详细地，驱动进程的实时状态信息(包括异常信息)会记录在一个core文件中，core文件存储在接口板310的内存中。然后，中央处理单元311的异常监控进程会从内存中查找core文件，进而生成携带core文件的ipc报文(如图3所示)作为异常上报报文。

中央处理单元311生成接管ipc进程将携带core文件的异常上报报文发送到ipc芯片312。详细地，中央处理单元311查找到全局主控板330的mac地址为目的mac地址，以本板(接口板310)的mac地址为源mac，生成携带core文件的ipc报文作为异常上报报文，然后以接口板320(对端接口板)的转发芯片321为目的芯片，以转发芯片321上连接ipc芯片322的转发芯片端口为目的端口，以本板的mac地址为源mac地址，以本板转发芯片313上连接本板ipc芯片的转发芯片端口为源端口，异常上报报文封装系统转发头(systemheader)，并在所述系统转发头外封装远端处理单元头(remotecpuheader，rcpuheader)。远端处理单元头包括接口板310中指定的转发芯片313的芯片端口。

接口板310的ipc芯片312将封装了远端处理单元头以及系统转发头的异常上报报文发往接口板310的转发芯片313。

接口板310的转发芯片313接收到异常上报报文后，剥掉远端处理单元头，根据系统转发头的目的芯片标识将带有系统转发头的异常上报报文发往对端接口板(接口板320)的转发芯片321。详细地，对端接口板可以是机框32中能够跨框进行通信的任意一个接口板320。

转发芯片321接收到异常上报报文后，确定系统转发头中的目的芯片标识是自身的芯片标识，剥掉异常上报报文的系统转发头，通过系统转发头中目的端口，即转发芯片321上连接ipc芯片322的端口，发送异常上报报文。

接口板320的ipc芯片322接收到异常上报报文后，根据异常上报报文中的目的mac地址查找对应的出端口将异常上报报文发送到全局主控板330的ipc芯片332，然后ipc芯片332确定异常上报报文的目的mac地址是本板的mac地址，将异常上报报文发送本板的控制单元331进行记录。全局主控板330的控制单元331可根据收到接口板310的core文件用以定位接口板310的故障原因。

进一步地，请参阅图4，是本公开实施例提供的一种接口板40的示意图。接口板400包括中央处理单元411、ipc芯片412、一个以上存储器413以及转发芯片414。一个以上存储413中存储有指令，中央处理单元411运行存储在一个以上存储器413中的指令，以实现上述实施例中所述的异常处理方法。详细地，接口板400作为与全局主控板同框的接口板，即图2所示的接口板210；接口板400也可作为与全局主控板不同框的接口板，即图3所示的接口板310相同，关于接口板400的详细描述可以参照上述对接口板210以及接口板310的详细内容，此处不再赘述。

综上所述，通过本公开的上述方案，无论出现异常的接口板与全局主控板处于同一机框还是不同机框，都可以在接口板的驱动进程发生异常时及时将包含驱动进程的异常信息的core文件及时传递到全局主控板，避免了core文件丢失，提高了接口板故障原因定位的可靠性。

在本公开所提供的实施例中，应该理解到，所揭露的设备和方法，也可以通过其它的方式实现。以上所描述的设备和方法实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本公开的多个实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本公开各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

对于本领域技术人员而言，显然本公开不限于上述示范性实施例的细节，而且在不背离本公开的精神或基本特征的情况下，能够以其它的具体形式实现本公开。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本公开的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本公开内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。