CN117082017A - 一种白盒交换机扩展卡管理的方法及装置 - Google Patents

Abstract

本说明书公开了一种白盒交换机扩展卡管理的方法及装置，接收管理指令，根据所述管理指令，在各扩展卡中确定所述管理指令对应的扩展卡，作为目标扩展卡，获取数据库中预存的所述目标扩展卡对应的接口函数，根据所述接口函数，对所述管理指令进行封装，根据封装后的管理指令与所述目标扩展卡进行交互，实现了通过白盒交换机自身的操作系统对扩展卡直接进行管理。

Description

一种白盒交换机扩展卡管理的方法及装置

技术领域

本说明书涉及计算机技术领域，尤其涉及一种白盒交换机扩展卡管理的方法及装置。

背景技术

近年来，白盒交换机广泛应用于数据中心、云计算、企业网络等各种场景。有别于将交换机硬件设备与操作系统集成在一起的传统交换机，白盒交换机实现了硬件设备与操作系统的解耦，由此，用户可以根据自身需要扩展白盒交换机的硬件模块并对白盒交换机中搭载的操作系统进行灵活地更改。

为了扩展白盒交换机的功能以适应不同的应用场景，为白盒交换机添加扩展卡是常用的解决手段，但是控制系统各异的扩展卡，难以通过白盒交换机搭载的操作系统直接进行配置和管理。

由此可见，如何通过白盒交换机自身的操作系统对扩展卡进行管理是一个亟待解决的问题。

发明内容

本说明书提供一种白盒交换机扩展卡管理的方法及装置，以部分的解决现有技术存在的上述问题。

本说明书采用下述技术方案：

本说明书提供了一种白盒交换机扩展卡管理的方法，应用于白盒交换机操作系统，所述白盒交换机与至少一个扩展卡相连，所述方法包括：

接收管理指令；

根据所述管理指令，在各扩展卡中确定所述管理指令对应的扩展卡，作为目标扩展卡；

获取数据库中预存的所述目标扩展卡对应的接口函数；

根据所述接口函数，对所述管理指令进行封装；

根据封装后的管理指令与所述目标扩展卡进行交互。

可选的，获取数据库中预存的所述目标扩展卡对应的接口函数，具体包括：

根据所述管理指令的类型和指令内容，在数据库中预存的所述目标扩展卡对应的接口函数中，获取目标接口函数。

可选的，所述管理指令包括配置指令；

根据封装后的管理指令与所述目标扩展卡进行交互，具体包括：

将封装后的配置指令发送给所述目标扩展卡，使所述目标扩展卡根据所述配置指令更新自身配置。

可选的，所述管理指令包括读取指令；

根据封装后的管理指令与所述目标扩展卡进行交互，具体包括：

将封装后的读取指令发送给所述目标扩展卡，以读取目标扩展卡的状态信息。

可选的，读取目标扩展卡的状态信息，具体包括：

接收目标扩展卡上传的状态报告；

根据所述接口函数，对所述状态报告进行解析，得到目标扩展卡的状态信息。

可选的，还包括：

当至少一个扩展卡运行状态发生改变，将运行状态改变的扩展卡作为更新扩展卡，获取所述更新扩展卡上传的状态报告；

在数据库中获取所述更新扩展卡对应的接口函数，作为更新接口函数；

根据所述更新接口函数，对更新扩展卡上传的状态报告进行解析，得到更新状态信息；

将所述更新状态信息存入数据库，以使在接收到目标扩展卡为所述更新扩展卡的读取指令时，读取数据库中存储的所述更新扩展卡的更新状态信息。

可选的，还包括：

当为白盒交换机添加扩展卡时，将添加的扩展卡对应的接口函数存入数据库。

本说明书提供了一种白盒交换机扩展卡管理的装置，应用于白盒交换机操作系统，所述白盒交换机与至少一个扩展卡相连，所述装置包括：

接收模块，接收管理指令；

确定模块，根据所述管理指令，在各扩展卡中确定所述管理指令对应的扩展卡，作为目标扩展卡；

获取模块，获取数据库中预存的所述目标扩展卡对应的接口函数；

封装模块，根据所述接口函数，对所述管理指令进行封装；

交互模块，根据封装后的管理指令与所述目标扩展卡进行交互。

本说明书提供了一种计算机可读存储介质，所述存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述一种白盒交换机扩展卡管理的方法。

本说明书提供了一种设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述一种白盒交换机扩展卡管理的方法。

本说明书采用的上述至少一个技术方案能够达到以下有益效果：

在本说明书提供的一种白盒交换机扩展卡管理的方法中，接收管理指令，根据所述管理指令，在各扩展卡中确定所述管理指令对应的扩展卡，作为目标扩展卡，获取数据库中预存的所述目标扩展卡对应的接口函数，根据所述接口函数，对所述管理指令进行封装，根据封装后的管理指令与所述目标扩展卡进行交互。

从上述方法中可以看出，本方法通过在数据库中预存各扩展卡所对应的接口函数，利用该接口函数对操作系统与扩展卡之间的交互信息进行处理，实现了通过白盒交换机自身的操作系统对扩展卡直接进行管理。

附图说明

此处所说明的附图用来提供对本说明书的进一步理解，构成本说明书的一部分，本说明书的示意性实施例及其说明用于解释本说明书，并不构成对本说明书的不当限定。在附图中：

图1为本说明书中一种白盒交换机扩展卡管理的方法的流程示意图；

图2为本说明书中扩展卡管理容器在SONiC系统中的应用示意图；

图3为本说明书中数据库订阅列表的示意图；

图4为本说明书中一种白盒交换机扩展卡管理的装置的示意图；

图5为本说明书提供的对应于图1的电子设备示意图。

具体实施方式

为使本说明书的目的、技术方案和优点更加清楚，下面将结合本说明书具体实施例及相应的附图对本说明书技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本说明书一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

以下结合附图，详细说明本说明书各实施例提供的技术方案。

图1为本说明书中一种白盒交换机扩展卡管理的方法的流程示意图，该白盒交换机扩展卡管理的方法具体包括以下步骤：

S100：接收管理指令。

由于白盒交换机具有软硬件解耦，可适应于各种应用场景进行灵活扩展的特点，各领域用户进行网络部署时越来越多地选择了白盒交换机。但是，在用户对白盒交换机的功能进行扩展时，由于各扩展卡的控制系统与白盒交换机所搭载的操作系统往往并不遵循统一的接口协议，如果想对该扩展卡进行管理，需要通过远程登录的手段登录到该扩展卡的控制系统，难以通过白盒交换机自身的操作系统达成。本说明书所提供的技术方案可以集成在白盒交换机操作系统中，在白盒交换机上电启动后，直接开始运行；也可以利用容器化技术将开发完成的扩展卡管理容器发布为容器镜像，在白盒交换机上电启动后，将所述容器镜像加载到白盒交换机操作系统中。

在实际应用的场景中，白盒交换机操作系统通过一个交互界面接收用户的管理指令，并将该管理指令的执行结果反馈到该交互界面上。以SONiC(Software for OpenNetworking in the Cloud)系统为例，用户通过命令行界面输入管理指令，操作系统接收并执行该管理指令后将该管理指令的响应结果通过命令行界面输出给用户。由于本说明书提供的技术方案用于对扩展卡而非白盒交换机原生硬件进行管理，需要对白盒交换机原操作系统的管理指令的类型进行扩展，加入管理扩展卡的指令。从而响应于用户输入的管理指令，该操作系统在接收到管理指令后，首先检测该指令的指令格式是否符合该操作系统的要求，若不符合要求，则反馈出错误提示；否则，继续检测该管理指令的指令类型，若为管理扩展卡的指令类型，则，调用本说明书提供的方法进行后续步骤，否则，调用原操作系统完成后续步骤。

S102：根据所述管理指令，在各扩展卡中确定所述管理指令对应的扩展卡，作为目标扩展卡。

当检测到该管理指令的指令类型属于管理扩展卡的指令类型之后，分析该管理指令的指令内容，根据该指令内容得到该管理指令所要管理的扩展卡，将该扩展卡作为目标扩展卡。

S104：获取数据库中预存的所述目标扩展卡对应的接口函数。

为了实现通过白盒交换机自身的操作系统直接对扩展卡进行管理，本说明书提供的技术方案在白盒交换机操作系统的数据库中预存了该扩展卡对应的接口函数，从而在执行管理扩展卡的管理指令时，可根据该管理指令所对应的目标扩展卡，从数据库中提取出该目标扩展卡对应的接口函数。其中，存储该接口函数的数据库可为原操作系统自带的数据库；各扩展卡对应的接口函数可由配置人员手动存入数据库。

在本说明书的一个或多个实施例中，当为白盒交换机添加扩展卡时，将添加的扩展卡对应的接口函数存入数据库。

使用本说明书提供的技术方案的白盒交换机，在添加扩展卡时，只需向白盒交换机操作系统的数据库中存入该扩展卡对应的接口函数，而无需对该操作系统自身进行更改，也无需通过远程登录等手段对扩展卡进行配置，即可通过该操作系统对添加的扩展卡直接进行管理。由此，增加了白盒交换机的可拓展性，也降低了扩展卡的管理难度。

S106：根据所述接口函数，对所述管理指令进行封装。

根据前文所述，当各扩展卡与白盒交换机原操作系统并不遵循统一的接口协议，若扩展卡直接接收白盒交换机原操作系统发出的管理指令，扩展卡的控制系统无法解析该管理指令从而无法执行该管理指令的指令内容。此时，利用提取出的接口函数对该管理指令进行封装，将该管理指令转化为各扩展卡的控制系统可解析的形式。

S108：根据封装后的管理指令与所述目标扩展卡进行交互。

将各封装后的管理指令发送给与该封装后的管理指令对应的目标扩展卡，使各目标扩展卡执行该封装后的管理指令的指令内容。

基于图1所述的一种白盒交换机扩展卡管理的方法，接收管理指令，根据所述管理指令，在各扩展卡中确定所述管理指令对应的扩展卡，作为目标扩展卡，获取数据库中预存的所述目标扩展卡对应的接口函数，根据所述接口函数，对所述管理指令进行封装，根据封装后的管理指令与所述目标扩展卡进行交互，通过在数据库中预存各扩展卡所对应的接口函数，利用该接口函数对操作系统与扩展卡之间的交互信息进行处理，实现了对通过白盒交换机自身的操作系统直接管理扩展卡。

另外，在如图1所示的步骤S104中，根据所述管理指令的类型和指令内容，在数据库中预存的所述目标扩展卡对应的接口函数中，获取目标接口函数。

对于一张扩展卡来说，其功能并不一定是单一的，即该扩展卡可以根据不同的业务逻辑实现不同的功能，则对于不同的功能该扩展卡可以设置不同的接口函数。因此，在获取管理指令对应的接口函数时，不仅要确定目标扩展卡，还要根据该管理指令的指令内容，确定该管理指令所要管理的目标扩展卡的功能，从而获取与该功能对应的目标接口函数。

在如图1所示的步骤S108中,所述管理指令包括配置指令，将封装后的配置指令发送给所述目标扩展卡，使所述目标扩展卡根据所述配置指令更新自身配置。

当各扩展卡初次接入白盒交换机时，需要对各扩展卡进行配置下发，同时在白盒交换机运行策略更改时，也需要对各扩展卡的运行配置进行更新。则响应于用户输入的配置指令，对该配置指令进行封装，并将封装后的配置指令发送给目标扩展卡，使所述目标扩展卡根据所述配置指令更新自身配置，以适应白盒交换机的运行策略。

在如图1所示的步骤S108中,所述管理指令还可包括读取指令，白盒交换机自身的操作系统根据该读取指令读取各目标扩展卡的状态信息，可采用以下两种方式：

第一种：将封装后的读取指令发送给所述目标扩展卡，以读取目标扩展卡的状态信息。

在白盒交换机的使用过程中，用户需要对交换机各组件的状态信息保持了解，以进行故障排查或调整运行策略，其中自然包括扩展卡的状态信息。则响应于用户输入的读取指令，对该读取指令进行封装，将封装后的读取指令发送给目标扩展卡，以读取目标扩展卡的状态信息，并将读取到的状态信息通过交互界面反馈给用户。其中，当目标扩展卡在预设时间内对于封装后的读取指令未作出回应，则直接将错误信息通过交互界面反馈给用户。

进一步的，接收目标扩展卡上传的状态报告，根据所述接口函数，对所述状态报告进行解析，得到目标扩展卡的状态信息。

在将封装后的读取指令发送给目标扩展卡之后，目标扩展卡根据该状态信息向白盒交换机的控制系统上报自身的状态报告，此时，该状态报告所使用的函数适用于该目标扩展卡自身的控制系统，即该状态报告无法直接被白盒交换机的控制系统读取，因此，使用该目标扩展卡对应的接口函数对状态报告进行解析，以得到可为白盒交换机的控制系统理解的状态信息，并将该状态信息通过交互界面反馈给用户。

第二种：当至少一个扩展卡运行状态发生改变，将运行状态改变的扩展卡作为更新扩展卡，获取所述更新扩展卡上传的状态报告，在数据库中获取所述更新扩展卡对应的接口函数，作为更新接口函数，根据所述更新接口函数，对更新扩展卡上传的状态报告进行解析，得到更新状态信息，将所述更新状态信息存入数据库，以使在接收到读取指令时，直接读取数据库中存储的该读取指令所要读取的目标扩展卡的更新状态信息。

即当至少一个扩展卡的运行状态改变时，该扩展卡将自身状态报告上传给白盒交换机的控制系统，该控制系统将该状态报告解析得到的状态信息存入数据库，从而使得该控制系统可响应于用户输入的读取指令，直接读取数据库中存储的该读取指令对应的目标扩展卡的状态信息，并将该状态信息通过交互界面反馈给用户。这一流程利用数据库将扩展卡状态信息的上报与读取的流程分离开，降低了响应用户输入的读取指令的响应时间。其中，在读取数据库中存储的该读取指令对应的目标扩展卡的状态信息时，还可读取该状态信息对应的存入时间，将该存入时间与通过控制系统获得的当前时间进行比对，若两者的差值超过预设的时间间隔，则使用前文提供的第一种方法读取目标扩展卡的状态信息。

以下将SONiC系统作为本说明书提供的技术方案应用的白盒交换机操作系统，将本说明书提供的技术方案以扩展卡管理容器的形式搭载于该SONiC系统中，给出本发明提供的技术方案的具体实施例。如图2所示,该扩展卡管理容器与白盒交换机的SONiC系统的redis（Remote Dictionary Server）数据库连接，该SONiC系统通过命令行模块实现与用户的交互。扩展卡管理容器内设扩展卡抽象单元，用于对每个扩展卡进行管理，各扩展卡抽象单元由redis接口、main（）（主进程）、底层接口组成，具体实施方案如下：

步骤1、获取用户的命令行输入，检测指令的有效性并判断用户输入的指令类型，所述指令类型包括扩展卡状态读取类和配置下发类两种。

所述步骤1中，所述检测指令的有效性包括但不限于指令名称、指令参数数量、指令参数格式。

在白盒交换机操作系统SONiC当中扩展命令行，包括扩展命令行对应的redis数据库，可以通过以下步骤来完成：

第一步、在sonic-buildimage/dockers/docker-database/database_config.json.j2数据库配置文件中新增扩展卡配置数据库，通过增加一个“DAUGHTER_CARD_CONFIG_DB”的json对象，其中包括了“id”、“separator”和“instance”等子对象。“id”值定义为14，代表着“DAUGHTER_CARD_CONFIG_DB”对应的时redis 的14号数据库，该数据库没有被原生的SONiC系统当中其他组件使用，因而对该数据库的操作不会影响其他业务的流程。

第二步、在sonic-buildimage/src/sonic-utilities/config/main.py文件中，config（配置）的组中添加dcard_config子命令。具体的，通过SONiC预先封装好的config类，调用该类的add_command接口，例如，config.add_command(dcard_config.dcard_config)。

第三步、新增sonic-buildimage/src/sonic-utilities/config/dcard_config.py中连接redis中14号数据库，获取连接对象。调用SONiC封装好的“SonicV2Connector”接口，如：dcard_config_db = SonicV2Connector(host='127.0.0.1')。

第四步、在dcard_config.py当中添加扩展卡配置命令，通过调用dcard_config类的command接口实现。例如通过“@dcard_config.command('tsn')”将添加了tsn（Time-Sensitive Networking）命令的dcard_config.command接口作为装饰器，以及通过“click.argument”接口也设置为装饰器（该接口可以对入参进行设置和检查），共同装饰后续定义的“tsn_dcard_config_entry”接口，tsn_dcard_config_entry就是对tsn命令的具体执行函数。在执行函数tsn_dcard_config_entry当中，可以获取tsn命令的参数作为函数的入参，从而针对这些入参信息调用redis数据库接口（如db.set等），基于后续的设计，将tsn命令的入参信息重新组织后，写入数据库当中。

步骤2、当判断用户输入为扩展卡状态读取类指令，读取白盒交换机操作系统的数据库当中对应扩展卡状态的键值信息，并将所述键值信息重新排版后打印在命令行交互终端。

所述步骤2中，所述扩展卡状态读取类指令，包括但不限于扩展卡身份状态、扩展卡资源状态、扩展卡业务状态。

扩展卡状态读取类指令类似于交换机当中的获取端口状态、获取vlan(VirtualLAN)状态等等，原生SONiC系统当中，类似的指令是直接读取4号数据库，然后将读取出的信息重新排版后打印在终端上。针对扩展卡的状态信息的读取，可以参考SONiC原生系统的逻辑，例如想要获取某个扩展卡的在线状态，可以在redis 的14号数据库当中设计一个字符串类型的数据，数据键为“OnlineState|DCard1”，以‘|’为分隔符也是同一族数据的常用设计方法，‘|’前表示该数据键对应的是在线状态信息，‘|’后则是扩展卡ID，以“DCard1”简单对扩展卡进行编码。

在命令行设计方面，通过扩展show命令实现上述的扩展卡状态读取，具体的，通过输入“sudo show dcard_state dcard1”来获取扩展卡1的状态。基于上述的各个步骤，在sonic-buildimage/src/sonic-utilities/config/main.py等文件当中添加相应的命令行扩展接口和相应的接口修饰代码，然后定义“state_dcard_show_entry”用于具体执行上述的扩展show命令。在“state_dcard_show_entry”函数当中，通过redis数据库接口“db.get”,直接读取redis的14号数据库，向数据库发送“GET OnlineState|DCard1”请求，若redis返回“ONLINE”（或者其他代表在线状态的数据），则表示扩展卡在线。命令行模块收到redis返回的数据后，可以调用SONiC封装的终端打印接口click.echo，将“DCard1”的在线情况打印到终端命令行窗口。

步骤3、当判断用户输入为扩展卡配置下发类指令，则解析指令的参数信息，调用白盒交换机操作系统数据库的交互接口，将指令信息写入所述数据库，并基于数据库通知机制，向扩展卡管理容器中的扩展卡抽象单元发送消息通知。

所述步骤3中所述向扩展卡管理容器中的扩展卡抽象单元发送消息通知，具体包括键通知和通道通知两种。

继续以tsn命令为例，通过“config tsn|DCard1 ＜mac-macDa＞ ＜vlanId-vlan＞ ＜inPort-port＞ ＜…＞”命令来配置扩展卡DCard1（DCard1即为数据库中该扩展卡的ID值）的TSN相关功能，使其可以处理时间敏感网络相关的数据流。针对TSN功能的配置不仅仅包含上述命令里的mac、vlan、port，还有destMap等其他信息，为了叙述方便对命令进行简化。

在获取到所述的“config tsn|DCard1 ＜mac-macDa＞ ＜vlanId-vlan＞ ＜inPort-port＞ ＜…＞”命令后，执行函数tsn_dcard_config_entry会传入命令行当中的＜mac-macDa＞、＜vlanId-vlan＞、＜inPort-port＞等信息，执行函数可以调用redis数据库接口db.hset，将“tsn|DCard1 mac ＜mac-macDa＞ vlan ＜vlanId-vlan＞ inport ＜inPort-port＞ …”交互请求发送给redis服务器，向redis 的14号数据库当中写入一个哈希类型的数据，该数据的键是“tsn|DCard1”，域是“mac”、“vlan”、“inport”等，对应的值是命令行参数＜mac-macDa＞、＜vlanId-vlan＞、＜inPort-port＞等。

如果采用的是键订阅的话，执行函数tsn_dcard_config_entry完成上述操作即足够了，redis服务器会自动向订阅了“tsn|DCard1”键的客户端（后续叙述的扩展卡管理容器当中的扩展卡抽象单元进程）发送数据通知，通知的内容即为“tsn|DCard1 mac ＜mac-macDa＞ vlan ＜vlanId-vlan＞ inport ＜inPort-port＞ …”，接收到消息的客户端可以根据消息内容进行后续的处理和动作。

键订阅逻辑上比较方便，但需要订阅方客户端预先知晓所有需要关注的数据键，如果需要对数据键进行扩展，则需要改动源码，灵活性上有所欠缺。因而，另一种进行消息通知的方法是通过通道进行订阅和发布。针对每一个扩展卡，可以设置一对一或多对一的消息通道。例如，针对上述的tsn config命令，除了调用db.hset接口向数据库内写入消息以外，还调用db.publish向channel|DCard1通道，将“config tsn|DCard1 ＜mac-macDa＞＜vlanId-vlan＞ ＜inPort-port＞ ＜…＞”信息采用json等格式进行重新封装，而后通过redis的通道发布功能进行消息通知。

采用通道发布的方式进行消息通知，可以对消息的内容进行任意的扩展，但需要消息的接收方进行额外的解析和消息类型甄别等工作，适用于扩展卡业务扩展性要求较高的场景。

步骤4、扩展卡管理容器中的扩展卡抽象单元主进程接收到来自所述数据库的通知消息，对所述通知消息进行处理，具体包括以下步骤：

第一步、扩展卡抽象单元主进程创建数据库订阅列表，调用底层接口当中的创建订阅对象接口，通过流式协议，获取到订阅对象的信息流，对所述信息流进行解析获取到多个订阅对象信息，并填充到所述数据库订阅列表当中。其中，所述流式协议包括但不限于RESP（Redis Serialization Protocol）协议。

本实施例当中，以C语言实现扩展卡容器当中的扩展卡抽象单元，包括顶层接口、底层接口和事件处理模块。在扩展卡容器的源码当中，底层接口采用头文件的方式进行定义，以链接动态库的形式进行编译。扩展卡容器中有多个扩展卡抽象单元，每一个扩展卡抽象单元实际上是独立的main函数编译出来的独立的可运行的程序，通过supervisord管理工具（该工具用于管理linux进程，）在扩展卡管理容器当中并行运行。所有的扩展卡抽象单元进程编译时使用的是相同的底层接口头文件，甚至顶层接口和事件处理模块的源码也都完全一致，区别仅在于链接了不同的底层接口动态库。每一个动态库与白盒交换机的扩展卡一一对应，当有新的扩展卡需要安插到白盒交换机底板上时，只需要开发一套底层接口动态库，便可以实现对所述新安插的扩展卡的管理，从而保证了本发明所述方案良好的可扩展性。其中，创建订阅对象接口函数（create_subscribe_obj），用于让扩展卡抽象单元进程知晓需要订阅redis数据库的哪些键或哪些通道。由于不同扩展卡的业务不同，因而需要订阅的redis数据库的键或通道的数量、内容都有差别，如何通过一个接口函数获得不同数量和内容的订阅对象信息也是本发明的一个创新点，即通过流式协议（本发明采用RESP，同样的流式协议还有JSON（JavaScript Object Notation）等，但相较于JSON，RESP更加紧凑）通过调用一次接口即可获得多个订阅对象的信息。

本实施例根据实际的应用场景对RESP协议进行了部分改动。例如，当前扩展卡抽象单元进程理论上需要订阅redis数据库的“tsn|DCard1”、“tas|DCard1”键，以及“config|DCard1”通道，那么通过创建订阅对象接口函数获得的RESP流为“*3\r\n$10\r\ntsn|DCard1\r\n$10\r\ntas|DCard1\r\n@13\r\nconfig|DCard1”,其中最后一个单元采用@符替换了$符，代表的是最后一个订阅的为通道，以$代表后续订阅的为数据库的键，以@代表后续订阅的为数据库的通道。

扩展卡抽象单元的主进程在调用create_subscribe_obj函数时，只需传入一个内存缓冲区的指针以及该内存缓冲区长度的参数，即可获得上述的RESP流。当create_subscribe_obj函数生成的RESP流长度超过了传入的内存缓冲区长度，则create_subscribe_obj函数不会向内存缓冲区当中写入信息，只会修改传入的缓冲区长度参数（该参数也以指针方式传入），使其等于所需要的内存缓冲区长度；扩展卡抽象单元的主进程在调用了create_subscribe_obj函数后，内存缓冲区内容依旧为空，说明长度不足，根据修改后的长度参数，分配足够的内存缓冲区传入create_subscribe_obj函数。由此，可以兼容订阅信息非常复杂的扩展卡情形，进一步提高方案兼容性。

本实施例中，所述的数据库订阅列表采用C语言链表实现，链表当中的每一个节点项采用C语言的结构体定义，结构体当中包含如下项：

第1项、一个字符串指针，通过字符串的C语言基本类型存储前述的“tsn|DCard1”、“tas|DCard1”、“config|DCard1”等订阅对象信息；

第2项、一个状态描述符，用于保存该键或通道的订阅状态，包括是否订阅成功、是否有待处理的通知消息、是否有待发送给扩展卡的消息等；

第3项、一个类型描述符，用于保存是键订阅还是通道订阅；

第4项、一个套接字描述符，用于保存该订阅项的套接字fd（file descriptor），通过该fd可以获取到来自数据库的通知消息；

第5项、一个缓冲区入口指针，用于缓存来自数据库的通知消息以及需要。

具体的，参考图3，当前案例下，数据库订阅列表当中一共有三个表项单元，分别对应着“tsn|DCard1”、“tas|DCard1”两个键订阅和“config|DCard1”通道订阅。

所述的数据库订阅链表以及链表项结构体的定义均定义到公共头文件当中，便于底层接口模块能够包含这些声明，并提供给底层接口中的数据库订阅消息处理接口使用。

第二步、扩展卡抽象单元遍历数据库订阅列表，为列表中的每一个项创建面向白盒交换机开放网络操作系统数据库的订阅链接，并生成链接的套接字描述符。

本实施例当中，白盒交换机开放网络操作系统SONiC的redis数据库服务器可以采用本地地址“127.0.0.1”的TCP（Transmission Control Protocol）端口6379进行TCP链接的建立。具体的，调用unix接口socket创建套接字，通过接口connect将所述创建的套接字与地址“127.0.0.1”的6379端口进行连接。而后初始化一个pollfd类型的结构体数组poll_fd[POLL_MAX]，pollfd结构体在＜sys/poll.h＞头文件当中定义，主要需要赋值的项为fd和events。其中，fd即赋值为前面创建并连接了redis数据库服务器的套接字，events赋值为POLLIN，即等待输入的消息。具体的，参考图3，数据库订阅列表当中的三个项的fd赋值到了poll_fd[1]、[2]、[3]，poll_fd数组是从下标0开始计数的，本实施例中，扩展卡上报也是通过TCP链接的通道实现，poll_fd[0]则是约定赋值为扩展卡抽象单元进程跟扩展卡上的TCP服务端连接的套接字，用于轮询监听来自扩展卡上报的消息。

完成套接字的TCP连接后，还需要先发送COMMAND命令给redis数据库，才能建立起redis服务的客户端，COMMAND命令通过RESP协议封装后为“*1\r\n$7\r\ncommand\r\n”，将该字符串通过send接口发送给redis服务器，即可建立链接；而后，将订阅命令也通过RESP协议进行封装，例如“*2\r\n$9\r\nSUBSCRIBE\r\n$27\r\n_ _keyspace@0_ _:tsn|DCard1\r\n”对应“tsn|DCard1”键的订阅、“*2\r\n$9\r\nSUBSCRIBE\r\n$13\r\nconfig|DCard1\r\n”对应“config|DCard1”通道的订阅，而后将封装好的消息通过send函数发送给redis数据库服务器，即可完成订阅。

第三步、扩展卡抽象单元创建轮询列表，将所述第二步中生成的套接字描述符添加到轮询列表当中，轮询等待来自数据库的通知消息。

完成第二步当中的订阅过程后，如果redis数据库需要向订阅方发布通知，则会通过所述的TCP链接进行消息发送。扩展卡抽象单元进程只需要轮询等待所述套接字的状态，当处于可读状态时，即可调用recv或者read接口对数据进行读取。

本实施例当中采用poll接口实现轮询，即应用linux的IO多路复用技术。具体的，调用poll函数并传入步骤S41当中创建的poll_fd数组即可。当产生可读事件时，需要判断一下当前poll_fd的下标，如果下标为0，说明此时接收到的消息是来自扩展卡的上报；当下标大于0，则是来自redis数据库服务器的通知消息。

第四步、扩展卡抽象单元获取到来自所述数据库的通知消息，更新所述的数据库订阅列表，并调用底层接口当中的数据库通知消息处理接口，对接收到的消息进行处理。

通过pollfd结构体的revents项即可判断是否有可读事件发生，即是否有redis数据库服务器通知的消息。当判断有数据库通知的消息到达后，扩展卡抽象单元进程即调用底层接口当中的pulish_msg_handle接口处理来自数据库发布的通知消息。该接口是开放给扩展卡的开发/维护人员进行接口开发，最后通过动态库的方式链接到符号表。该接口实质上是对来自数据库通知消息的重新封装，例如数据库发送的通知消息，解析后缓存在图3所示的buf内存缓冲区当中，为“hset tsn|DCard1 mac 00:00:00:11:22:33 vlan 1001inport ethernet0/0/1”，同时对应的扩展卡采用json格式的流进行配置，即pulish_msg_handle需要将缓存在buf当中的消息重新封装为：“{"tsn|DCard1":{"mac":"00:00:00:11:22:33","vlan":1001,"inport": "ethernet0/0/1"}}”,重新填充的buf缓冲区当中，并将图3所示的state项的值修改为NEED_SENT_TO_SUBCARD。

第五步、扩展卡抽象单元完成一轮轮询等待后，调用底层接口当中的配置下发接口，遍历所述数据库订阅列表，将需要下发给扩展卡的配置消息进行下发，并更新所述的数据库订阅列表。

扩展卡抽象单元完成一轮轮询后，重新遍历数据库订阅列表，寻找state值为NEED_SENT_TO_SUBCARD的列表项，而后调用底层接口当中的publish_config接口，将此时缓冲区当中保存的":{"mac":"00:00:00:11:22:33","vlan":1001,"inport": "ethernet0/0/1"}}”信息下发给扩展卡。所述的publish_config接口同样由扩展卡的开发/维护人员进行接口开发，最后通过动态库的方式链接到符号表。本实施例当中，扩展卡通过TCP客户端-服务器的方式同扩展卡抽象单元进程进行消息交互，publish_config接口当中直接调用send函数即可完成配置的下发。在其他一些场景当中，扩展卡可能通过SPI、PCIe等多种底层链路进行数据收发，此时除了调用相关的接口外，还需要实现对应的linux驱动。

步骤5、扩展卡管理容器中的扩展卡抽象单元的主进程接收到来自所述扩展卡上报的消息，对所述上报的消息进行处理，具体包括以下步骤：

第一步、扩展卡抽象单元的主进程监听与扩展卡的消息交互链路；

第二步、扩展卡抽象单元的主进程监听到有消息上报，调用底层接口当中的上报消息读取接口，读取扩展卡上报的消息；

第三步、扩展卡抽象单元的主进程调用底层接口当中的上报消息处理接口，生成待写入白盒交换机开放网络操作系统数据库的消息，所述消息采用流式协议进行封装；

第四步、扩展卡抽象单元的主进程解析所述的待写入白盒交换机开放网络操作系统数据库的消息，并将解析后的信息写入所述数据库。

扩展卡上报消息的读取和处理过程与步骤4所述的数据库通知消息的读取和处理过程类似。本实施例当中，扩展卡通过TCP服务器-客户端的形式与扩展卡抽象单元的主进程建立TCP链接，subcard_msg_recv接口只需要重新封装一下linux的recv或read接口即可实现；扩展卡上报的消息采用json格式发送，subcard_msg_handle接口将json格式进行解析，并生成需要写回到数据库的状态信息。

扩展卡的一次上报消息可能需要对应多个数据库写入操作，即一个消息流当中包含了多个相互独立的数据对象。本实施例参照步骤4第一步当中描述的扩展RESP协议实现消息封装，subcard_msg_handle向一个内存缓冲区当中填入封装后的信息，扩展卡抽象单元的主进程再读取该内存缓冲区，转换成一个需要向redis数据库服务器发送的消息列表，所述消息列表采用C语言链表的形式即可组织。该列表可采用局部变量声明和定义，其作用域在本次扩展卡上报消息处理完成后，即可释放。扩展卡抽象单元主进程再通过redis数据库交互接口（hiredis），直接将图3所述列表当中的信息写入到数据库当中。

以上为本说明书的一个或多个实施例提供的一种白盒交换机扩展卡管理的方法，基于同样的思路，本说明书还提供了相应的一种白盒交换机扩展卡管理的装置，如图4所示。

图4为本说明书提供的一种白盒交换机扩展卡管理的装置示意图，具体包括：

一种白盒交换机扩展卡管理的装置，应用于白盒交换机操作系统，所述白盒交换机与至少一个扩展卡相连，所述装置包括：

接收模块400，接收管理指令；

确定模块402，根据所述管理指令，在各扩展卡中确定所述管理指令对应的扩展卡，作为目标扩展卡；

获取模块404，获取数据库中预存的所述目标扩展卡对应的接口函数；

封装模块406，根据所述接口函数，对所述管理指令进行封装；

交互模块408，根据封装后的管理指令与所述目标扩展卡进行交互。

可选的，所述获取模块404，具体用于：根据所述管理指令的类型和指令内容，在数据库中预存的所述目标扩展卡对应的接口函数中，获取目标接口函数。

可选的，所述管理指令包括配置指令，所述交互模块408，具体用于：将封装后的配置指令发送给所述目标扩展卡，使所述目标扩展卡根据所述配置指令更新自身配置。

可选的，所述管理指令包括读取指令，所述交互模块408，具体用于：将封装后的读取指令发送给所述目标扩展卡，以读取目标扩展卡的状态信息。

可选的，所述交互模块408，具体用于：接收目标扩展卡上传的状态报告；根据所述接口函数，对所述状态报告进行解析，得到目标扩展卡的状态信息。

可选的，所述交互模块408还用于：当至少一个扩展卡运行状态发生改变，将运行状态改变的扩展卡作为更新扩展卡，获取所述更新扩展卡上传的状态报告；在数据库中获取所述更新扩展卡对应的接口函数，作为更新接口函数；根据所述更新接口函数，对更新扩展卡上传的状态报告进行解析，得到更新状态信息；所述更新状态信息存入数据库，以使在接收到目标扩展卡为所述更新扩展卡的读取指令时，读取数据库中存储的所述更新扩展卡的更新状态信息。

可选的，所述装置还包括新增模块410，所述新增模块410具体用于：当为白盒交换机添加扩展卡时，将添加的扩展卡对应的接口函数存入数据库。

本说明书还提供了一种计算机可读存储介质，该存储介质存储有计算机程序，计算机程序可用于执行上述图1提供的一种白盒交换机扩展卡管理的方法。

本说明书还提供了图5所示的电子设备的示意结构图。如图5所述，在硬件层面，该白盒交换机扩展卡管理的设备包括处理器、内部总线、网络接口、内存以及非易失性存储器，当然还可能包括其他业务所需要的硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，以实现上述图1所述的一种白盒交换机扩展卡管理的方法。当然，除了软件实现方式之外，本说明书并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进（例如，对二极管、晶体管、开关等电路结构的改进）还是软件上的改进（对于方法流程的改进）。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件（Programmable Logic Device, PLD）（例如现场可编程门阵列（Field Programmable GateArray，FPGA））就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器（logic compiler）”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言（Hardware Description Language，HDL），而HDL也并非仅有一种，而是有许多种，如ABEL（Advanced Boolean Expression Language）、AHDL（Altera Hardware DescriptionLanguage）、Confluence、CUPL（Cornell University Programming Language）、HDCal、JHDL（Java Hardware Description Language）、Lava、Lola、MyHDL、PALASM、RHDL（RubyHardware Description Language）等，目前最普遍使用的是VHDL（Very-High-SpeedIntegrated Circuit Hardware Description Language）与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该（微）处理器执行的计算机可读程序代码（例如软件或固件）的计算机可读介质、逻辑门、开关、专用集成电路（Application Specific Integrated Circuit，ASIC）、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20 以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本说明书时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备（系统）、和计算机程序产品的流程图和／或方框图来描述的。应理解可由计算机程序指令实现流程图和／或方框图中的每一流程和／或方框、以及流程图和／或方框图中的流程和／或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本说明书的实施例可提供为方法、系统或计算机程序产品。因此，本说明书可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本说明书可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。

本说明书可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本说明书的实施例而已，并不用于限制本说明书。对于本领域技术人员来说，本说明书可以有各种更改和变化。凡在本说明书的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (10)

1.一种白盒交换机扩展卡管理的方法，其特征在于，应用于白盒交换机操作系统，所述白盒交换机与至少一个扩展卡相连；所述方法包括：

接收管理指令；

根据所述管理指令，在各扩展卡中确定所述管理指令对应的扩展卡，作为目标扩展卡；

获取数据库中预存的所述目标扩展卡对应的接口函数；

根据所述接口函数，对所述管理指令进行封装；

根据封装后的管理指令与所述目标扩展卡进行交互。

2.如权利要求1所述的方法，其特征在于，获取数据库中预存的所述目标扩展卡对应的接口函数，具体包括：

根据所述管理指令的类型和指令内容，在数据库中预存的所述目标扩展卡对应的接口函数中，获取目标接口函数。

3.如权利要求1所述的方法，其特征在于，所述管理指令包括配置指令；

根据封装后的管理指令与所述目标扩展卡进行交互，具体包括：

将封装后的配置指令发送给所述目标扩展卡，使所述目标扩展卡根据所述配置指令更新自身配置。

4.如权利要求1所述的方法，其特征在于，所述管理指令包括读取指令；

根据封装后的管理指令与所述目标扩展卡进行交互，具体包括：

将封装后的读取指令发送给所述目标扩展卡，以读取目标扩展卡的状态信息。

5.如权利要求4所述的方法，其特征在于，读取目标扩展卡的状态信息，具体包括：

接收目标扩展卡上传的状态报告；

根据所述接口函数，对所述状态报告进行解析，得到目标扩展卡的状态信息。

6.如权利要求4所述的方法，其特征在于，还包括：

当至少一个扩展卡运行状态发生改变，将运行状态改变的扩展卡作为更新扩展卡，获取所述更新扩展卡上传的状态报告；

在数据库中获取所述更新扩展卡对应的接口函数，作为更新接口函数；

根据所述更新接口函数，对更新扩展卡上传的状态报告进行解析，得到更新状态信息；

将所述更新状态信息存入数据库，以使在接收到目标扩展卡为所述更新扩展卡的读取指令时，读取数据库中存储的所述更新扩展卡的更新状态信息。

7.如权利要求1所述的方法，其特征在于，还包括：

当为白盒交换机添加扩展卡时，将添加的扩展卡对应的接口函数存入数据库。

8.一种白盒交换机扩展卡管理的装置，其特征在于，应用于白盒交换机操作系统，所述白盒交换机与至少一个扩展卡相连，所述装置包括：

接收模块，接收管理指令；

确定模块，根据所述管理指令，在各扩展卡中确定所述管理指令对应的扩展卡，作为目标扩展卡；

获取模块，获取数据库中预存的所述目标扩展卡对应的接口函数；

封装模块，根据所述接口函数，对所述管理指令进行封装；

交互模块，根据封装后的管理指令与所述目标扩展卡进行交互。

9.一种计算机可读存储介质，其特征在于，所述存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述权利要求1~7任一项所述的方法。

10.一种设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现上述权利要求1~7任一项所述的方法。