并行用户态协议栈的管理方法和协议栈系统的制作方法
【技术领域】
[0001]本发明实施例涉及计算机领域，并且更具体地，涉及一种并行用户态协议栈的管理方法和协议栈系统。
【背景技术】
[0002]随着以太网技术的发展，10G、40G网卡的出现和普及，传统基于单核的协议栈已经无法跟上网卡速度的需要。此外，处理器体系结构已从强调高频单处理器发展到多核多处理器，计算机的并行处理能力越来越强。
[0003]现有技术中，数据包在多个协议栈实例之间分发时，采用公用的分发模块以连接作为粒度进行数据分发，分发模块可能成为系统的分发瓶颈，在负载均衡和负载故障恢复时需要维护大量的数据，消耗较多的系统时间，不利于负载的连接数据的快速恢复。在并行协议栈中如何快速进行负载均衡和故障恢复，是需要考虑解决的问题。
【发明内容】
[0004]本发明实施例提供一种并行用户态协议栈的管理方法和协议栈系统，能够克服协议栈共用一个分发模块带来的系统分发瓶颈，快速进行负载均衡和故障恢复，提高协议栈系统的性能。
[0005]第一方面，提供了一种并行用户态协议栈的管理方法，该方法包括:监控用户态协议栈中每个协议栈对应的实例的运行状态，一个该实例对应于该用户态协议栈中的一个协议栈；确定第一实例和第二实例，其中该第一实例为运行状态异常的实例，该第二实例具备迁入该第一实例中至少一个待迁移负载的能力，一个该待迁移负载在该第一实例所对应的协议栈内对应于一个协议控制块PCB，该PCB在共享资源池中对应于一个存储着该待迁移负载连接参数的PCB，该待迁移负载的连接参数能够用于重建该待迁移负载；根据该第一实例中至少一个待迁移负载在该共享资源池中所对应的PCB在该第二实例中重建该至少一个待迁移负载。
[0006]结合第一方面，在第一种可能的实现方式中，在该根据该第一实例中至少一个待迁移负载在共享资源池中所对应的协议控制块PCB在该第二实例中重建该至少一个待迁移负载之前，该方法还包括:确定该第一实例中的至少一个待迁移负载。
[0007]结合第一方面的第一种可能的实现方式，在第二种可能的实现方式中，该实例的运行状态包括实例的负载状态和存活状态，该监控用户态协议栈中每个协议栈对应的实例的运行状态包括:分别向该用户态协议栈中每个协议栈对应的实例发送心跳消息并监控该心跳消息响应时延，并监控该用户态协议栈中每个协议栈对应的实例在第一预定时间内的实例负载均值，以根据该心跳消息的响应时延和该实例负载均值确定该用户态协议栈中每个协议栈对应的实例的运行状态，其中，一条心跳消息对应于一个该实例；或者分别轮询该用户态协议栈中每个协议栈对应的实例的实例标识，并监控该用户态协议栈中每个协议栈对应的实例在第一预定时间内的实例负载均值，以根据该实例标识和该实例负载均值确定该用户态协议栈中每个协议栈对应的实例的运行状态，其中，该实例标识用于表示实例的存活状态，该实例标识存储于共享内存区域或共享文件，一个该实例标识对应于一个该实例。
[0008]结合第一方面的第二种可能的实现方式，在第三种可能的实现方式中，确定第一实例具体实现为:确定距离发送心跳消息时刻达到第二预定时间后仍然未反馈心跳响应的实例为该第一实例；或者，确定第一预定时间内实例标识表示僵死或失效状态的实例为该第一实例。
[0009]结合第一方面的第三种可能的实现方式，在第四种可能的实现方式中，确定第二实例具体实现为创建并确定新的实例为该第二实例；此时，根据该第一实例中至少一个待迁移负载在共享资源池中所对应的协议控制块PCB在该第二实例中重建该至少一个待迁移负载具体实现为:根据该至少一个待迁移负载之第一负载在共享资源池中所对应的第一PCB在该第二实例中实现该第一负载与该用户态协议栈的上层服务的对接，并将该第一负载在该第一实例中绑定的第一接收端扩展RSS队列重绑定到该第二实例的该第一负载中，其中，该至少一个待迁移负载包括该第一实例的所有负载。
[0010]结合第一方面的第四种可能的实现方式，在第五种可能的实现方式中，该方法还包括:终止该第一实例。
[0011]结合第一方面的第二种可能的实现方式，在第六种可能的实现方式中，确定第一实例具体实现为:确定第一预定时间内实例总负载均值大于第一预定阈值的实例为该第一实例。
[0012]结合第一方面的第六种可能的实现方式，在第七种可能的实现方式中，确定第二实例具体实现为:如果存在第一预定时间内实例总负载均值低于第二预定阈值的实例，则确定该第一预定时间内实例总负载均值低于第二预定阈值的一个或多个实例作为该第二实例，其中，迁入该第二实例的所有负载的负载值与该第二预定阈值之和小于该第一预定阈值。
[0013]结合第一方面的第七种可能的实现方式，在第八种可能的实现方式中，根据该第一实例中至少一个待迁移负载在共享资源池中所对应的协议控制块PCB在该第二实例中重建该至少一个待迁移负载具体实现为:根据该第一实例的至少一个待迁移负载之第二负载在该共享资源池中所对应的第二 PCB，将该第二负载在该第一实例中绑定的第二 RSS队列的绑定规则修改为绑定到该第二实例的第二负载中，以使得该第二实例实现从该第二RSS队列进行数据包接收及处理的过程；或者，根据该第一实例的至少一个待迁移负载之第二负载在该共享资源池中所对应的第二 PCB，在该第一实例中解除该第二负载在该第一实例中绑定的第二 RSS队列，并在该第二实例中将该第二 RSS队列绑定到该第二负载中，以使得该第二实例实现从该第二 RSS队列进行数据包接收及处理的过程。
[0014]结合第一方面的第七种可能的实现方式或第一方面的第八种可能的实现方式，在第九种可能的实现方式中，确定该第一实例中的至少一个待迁移负载具体实现为:确定该第一实例中的第三负载为该第一实例的待迁移负载，其中该第三负载在该第一实例中所绑定的第三RSS队列满足以下条件:当该第三RSS队列绑定到该第二实例时该第二实例的连接数、接收字节数、发送字节数3个参数中至少有2个参数不大于该第一实例的相应参数。
[0015]结合第一方面的第六种可能的实现方式，在第十种可能的实现方式中，确定第二实例具体实现为:如果不存在预定时间内实例总负载均值低于第二预定阈值的实例，则创建并确定新的实例为该第二实例。
[0016]结合第一方面的第十种可能的实现方式，在第十一种可能的实现方式中，根据该第一实例中至少一个待迁移负载在共享资源池中所对应的协议控制块PCB在该第二实例中重建该至少一个待迁移负载具体实现为:根据该第一实例的至少一个待迁移负载之第二负载在该共享资源池中所对应的第二 PCB在该第二实例中实现该第二负载与该用户态协议栈的上层服务的对接以使得该第二实例实现与该第二负载对应的应用app的交互，并在该第一实例中解除该第二负载在该第一实例中绑定的第二 RSS队列，在该第二实例中将该第二 RSS队列绑定到该第二负载中，以使得该第二实例实现从该第二 RSS队列进行数据包接收及处理的过程。
[0017]结合第一方面的第十种可能的实现方式或第一方面的第十一种可能的实现方式，在第十二种可能的实现方式中，确定该第一实例中的至少一个待迁移负载具体实现为:确定该第一实例中的第三负载为该第一实例的待迁移负载，该第三负载在该第一实例中所绑定的第三RSS队列满足以下条件:该第三RSS队列的连接数、接收字节数、发送字节数3个参数中都达到该第一实例的所有负载中对应参数的均值。
[0018]第二方面，提供了一种协议栈系统，该系统包括:监控单元，用于监控该协议栈系统的用户态协议栈中每个协议栈对应的运行状态，一个该实例对应于该用户态协议栈中的一个协议栈；确定单兀，用于确定第一实例和第二实例，该第一实例为运行状态异常的实例，该第二实例具备迁入该第一实例中至少一个待迁移负载的能力，一个该待迁移负载在该第一实例所对应的协议栈内对应于一个协议控制块PCB,该PCB在该协议栈系统的共享资源池中对应于一个存储着该待迁移负载的连接参数的PCB，该待迁移负载的连接参数能够用于重建该待迁移负载；负载迁移单元，用于根据该第一实例中至少一个待迁移负载在该共享资源池中所对应的PCB在该第二实例中重建该至少一个待迁移负载。
[0019]结合第二方面，在第一种可能的实现方式中，该确定单元还用于确定该第一实例中的至少一个待迁移负载。
[0020]结合第二方面的第一种可能的实现方式，在第二种可能的实现方式中，该实例的运行状态包括实例的负载状态和存活状态，该监控单元具体用于:分别向该用户态协议栈中每个协议栈对应的实例发送心跳消息并监控该心跳消息响应时延，并监控该用户态协议栈中每个协议栈对应的实例在第一预定时间内的实例负载均值，以根据该心跳消息的响应时延和该实例负载均值确定该用户态协议栈中每个协议栈对应的实例的运行状态，其中，一条心跳消息对应于一个该实例；或者，分别轮询该用户态协议栈中每个协议栈对应的实例的实例标识，并监控该用户态协议栈中每个协议栈对应的实例在第一预定时间内的实例负载均值，以根据该实例标识和该实例负载均值确定该用户态协议栈中每个协议栈对应的实例的运行状态，其中，该实例标识用于表示实例的存活状态，该实例标识存储于共享内存区域或共享文件，一个该实例标识对应于一个该实例。
[0021]结合第二方面的第二种可能的实现方式，在第三种可能的实现方式中，在用于确定第一实例的过程中，该确定单元具体用于:确定距离发送心跳消息时刻达到第二预定时间后仍然未反馈心跳响应的实例为该第一实例；或者，确定第一预定时间内实例标识都表示僵死或失效状态的实例为该第一实例。
[0022]结合第二方面的第三种可能的实现方式，在第四种可能的实现方式中，在用于确定第二实例的过程中，该确定单元具体用于创建并确定新的实例为该第二实例；该负载迁移单元具体用于根据该至少一个待迁移负载之第一负载在共享资源池中所对应的第一 PCB在该第二实例中实现该第一负载与该用户态协议栈的上层服务的对接，并将该第一负载在该第一实例中绑定的第一接收端扩展RSS队列重绑定到该第二实例的该第一负载中，其中，该至少一个待迁移负载包括该第一实例的所有负载。
[0023]结合第二方面的第四种可能的实现方式，在第五种可能的实现方式中，该系统还包括:实例停止单元，用于终止该第一实例。
[0024]结合第二方面的第二种可能的实现方式，在第六种可能的实现方式中，在用于确定第一实例的过程中，该确定单元具体用于:确定第一预定时间内实例总负载均值大于第一预定阈值的实例为该第一实例。
[0025]结合第二方面的第六种可能的实现方式，在第七种可能的实现方式中，在用于确定该第二实例的过程中，该确定单元具体用于:如果存在第一预定时间内实例总负载均值低于第二预定阈值的实例，则确定预定时间内实例总负载均值低于第二预定阈值的一个或多个实例作为该第二实例，其中，迁入该第二实例的所有负载的负载值与该第二预定阈值之和小于该第一预定阈值。
[0026]结合第二方面的第七种可能的实现方式，在第八种可能的实现方式中，该负载迁移单元具体用于:根据该第一实例的至少一个待迁移负载之第二负载在该共享资源池中所对应的第二 PCB，将该第二负载在该第一实例中绑定的第二 RSS队列的绑定规则修改为绑定到该第二实例的第二负载中，以使得该第二实例实现从该第二 RSS队列进行数据包接收及处理的过程；或者，根据该第一实例的至少一个待迁移负载之第二负载在该共享资源池中所对应的第二 PCB，在该第一实例中解除该第二负载在该第一实例中绑定的第二 RSS队列，并在该第二实例中将该第二 RSS队列绑定到该第二负载中，以使得该第二实例实现从该第二 RSS队列进行数据包接收及处理的过程。
[0027]结合第二方面的第七种可能的实现方式或第二方面的第八种可能的实现方式，在第九种可能的实现方式中，在用于确定该第一实例中的至少一个待迁移负载的过程中，该确定单元具体用于:确定该第一实例中的第三负载为该第一实例的待迁移负载，该第三负载在该第一实例中所绑定的第三RSS队列满足以下条件:当该第三RSS队列绑定到该第二实例时该第二实例的连接数、接收字节数、发送字节数3个参数中至少有2个参数不大于该第一实例的相应参数。确定该第一实例中的至少一个待迁移负载具体实现为:确定该第一实例中的第三负载为该第一实例的待迁移负载，其中该第三负载在该第一实例中所绑定的第三RSS队列满足以下条件:当该第三RSS队列绑定到该第二实例时该第二实例的连接数、接收字节数、发送字节数3个参数中至少有2个参数不大于该第一实例的相应参数。
[0028]结合第二方面的第六种可能的实现方式，在第十种可能的实现方式中，在用于确定第二实例的过程中，该确定单元具体用于:如果不存在预定时间内实例总负载均值低于第二预定阈值的实例，则创建并确定新的实例为该第二实例。
[0029]结合第二方面的第十种可能的实现方式，在第i^一种可能的实现方式中，该负载迁移单元具体用于:根据该第一实例的至少一个待迁移负载之第二负载在该共享资源池中所对应的第二 PCB在该第二实例中实现该第二负载与该用户态协议栈的上层服务的对接以使得该第二实例实现与该第二负载对应的应用app的交互，并在该第一实例中解除该第二负载在该第一实例中绑定的第二 RSS队列，在该第二实例中将该第二 RSS队列绑定到该第二负载中，以使得该第二实例实现从