本发明涉及NFV之一的逻辑CPE设备，尤其涉及利用Docker技术进行逻辑CPE设备软件功能划分及部署的领域，具体是指一种基于Docker技术的逻辑CPE设备的虚拟化管理系统及其配置方法。
背景技术：
虚拟化已被确立为一种成熟可靠的技术，可以用来增强数据中心服务器和存储系统的容量、完善管理，以及提高效率。传统逻辑CPE设备通常为嵌入式的专有设备，比如在社区或用户家庭、办公室放置的ONT或ONU或者用户接入专用的VPN设备，逻辑CPE设备作为终端接入设备，具有很强的定制特性需求，如带宽、访问控制策略、业务功能等等，因而在逻辑上呈现为若干逻辑CPE设备的集合。
依据功能，逻辑CPE设备划分为管理层面(简称MP层面)、控制层面(简称CP层面)、数据层面(简称DP层面)。MP层面负责逻辑CPE设备的配置管理，CP层面负责用户接入、策略控制等控制协议的处理，DP层面负责控制报文与数据报文的分离以及数据报文的转发控制。
网络功能虚拟机化之后，逻辑CPE设备多以虚拟机(而非容器)的形态开始出现，由于DP层面对转发性能要求较高，这些虚拟化的逻辑CPE设备并未真实投入商用。与此同时，也有厂家开始考虑将CP层面虚拟化，仍将DP层面保留在专用设备内，CP层面相比DP层面，性能要求不高，追求的是部署的灵活性，Docker技术、ovs+dpdk(两者是一体的，指OVS和DPDK两项技术融合，目的是优化OVS的传输性能)等技术手段被先后引入，尽管如此，但DP层面仍为专有化设备实现与虚拟化的初衷是不吻合的。
传统的虚拟化实现方法通常有两类，一类是实现一个包罗所有策略、功能的大型虚拟设备，通过虚拟软件自身实现若干逻辑CPE设备的集合。另一类是，采用虚拟机技术，即一个逻辑CPE设备部署在一个或若干个虚拟机。由于虚拟设备固有的特性，前者对设备的高可用性是个考验，比如，一旦出现某个或某些逻辑CPE设备发生软件故障，影响将是全局的。对于后者，由于虚拟机技术是对包括CPU、内存、磁盘等所有硬件资源的虚拟化，需要专门的客户操作系统进行管理，这就存在资源消耗过大、二次调度响应不及时问题。
对于电信级的虚拟化通信设备，网络收发包的性能往往成为通信的瓶颈，通常需要消耗大量的CPU及内存资源。此外，基于降低网卡数量减少布线的考虑，逻辑CPE设备的数量与物理服务器的网卡数量是严重不对等的。而Docker技术通过容器实现计算机资源的隔离，包括进程ID、文件系统挂载点、网络、主机与域名等名字空间；这些隔离技术确保容器内的服务与其它容器互不干扰。同时各容器内的服务共享物理机操作系统，极大降低物理资源消耗。
因此，一种既满足必要的资源隔离，便于实现独立逻辑计算，又轻型部署方便的技术，是非常重要的。
技术实现要素：
本发明的目的是克服上述现有技术中的缺点，提供了一种既满足必要的资源隔离、便于实现独立逻辑计算，又轻型、部署方便的基于Docker技术的逻辑CPE设备的虚拟化管理系统及其配置方法。
为了实现上述的目的，本发明的基于Docker技术的逻辑CPE设备的虚拟化管理系统及其配置方法具体如下：
该基于Docker技术的逻辑CPE设备的虚拟化管理系统，其主要特点是，包括第一Docker容器、第二Docker容器、第三Docker容器和第四Docker容器，分别对应部署有逻辑CPE设备的DP层面、CP层面、MP层面和DP-manager，分别对应于逻辑CPE设备的DP层面、CP层面、MP层面和DP-manager的虚拟化管理。
较佳地，所述的第一Docker容器对多个逻辑CPE设备的DP层面进行虚拟化管理，且所述的第一Docker容器绑定至被管理终端的网络接口；第二Docker容器对单个逻辑CPE设备的CP层面进行虚拟化管理，第三Docker容器对单个逻辑CPE设备的MP层面进行虚拟化管理，第四Docker容器对单个逻辑CPE设备的DP-manager进行虚拟化管理。
更佳地，所述的第一Docker容器的数目为1个，所述的第二、第三和第四Docker容器的数目与该虚拟化管理系统中待管理的逻辑CPE设备的数目相一致。
更佳地，所述的第一Docker容器和第四Docker容器均为申请有共享内存的Docker容器，且所述的第一Docker容器和第四Docker容器通过共享内存进行数据交流，且所述的第四Docker容器之间写互斥。
较佳地，单个逻辑CPE设备的第二、第三和第四Docker容器之间通过配置管理桥相互连接，组成私有配置网络，且所述的第三Docker容器设置有对外服务端口以及北向配置管理接口。
更佳地，还包括流量识别单元，与所述的网络接口连接，对流经网络接口的流量进行流量识别，判断流量所属的逻辑CPE设备。
基于Docker技术的逻辑CPE设备的虚拟化管理系统的配置方法，其主要特点是，所述的配置方法为：
将逻辑CPE设备的DP层面、CP层面、MP层面和DP-manage部署到对应的Docker容器中。
更佳地，将逻辑CPE设备的DP层面、CP层面、MP层面和DP层面-manage部署到对应的Docker容器中时，包括以下步骤：
(1)将多个逻辑CPE设备的DP层面部署到第一Docker容器，并将所述的第一Docker容器绑定至被管理终端的网络接口；
(2)为所述的第一Docker容器申请共享内存，并对该第一Docker容器进行初始化；
(3)将DP-manager部署到第四Docker容器，为所述的第四Docker容器申请共享内存，并将第四Docker容器之间设置为写互斥；
(4)将逻辑CPE设备的CP层面、MP层面和DP层面-manage分别对应部署到第二、第三和第四Docker容器中。
更佳地，所述的部署包括以下步骤：
(a)制作Docker容器的镜像配置文件Dockerfile，并制定Docker容器的参数；
(b)执行Docker镜像制作命令，根据所述的镜像配置文件Dockerfile生成Docker容器镜像。
采用本发明的基于Docker技术的逻辑CPE设备的虚拟化管理系统及其配置方法，通过Docker容器技术实现逻辑CPE设备逻辑层面间的隔离，通过基于Docker容器技术的多逻辑CPE设备解决不同用户的定制特性需求，通过DP层面物理单实例、逻辑单实例解决虚拟化设备资源消耗大及转发效率低问题，具有以下技术效果：(1)各逻辑CPE设备松耦合，策略和功能定制化；(2)单个逻辑CPE设备宕机，对其它逻辑CPE设备映像降到最低；(3)DP层面物理上单实例，逻辑上多实例，极大降低物理资源消耗；(4)物理网络口有限，布线简化。
附图说明
图1为本发明的基于Docker技术的逻辑CPE设备的虚拟化管理系统的结构示意图。
具体实施方式
为了能够更清楚地理解本发明的技术内容，特举以下实施例详细说明。
该基于Docker技术的逻辑CPE设备的虚拟化管理系统，其中包括第一Docker容器、第二Docker容器、第三Docker容器和第四Docker容器，分别对应部署有逻辑CPE设备的DP层面、CP层面、MP层面和DP-manager，分别对应于逻辑CPE设备的DP层面、CP层面、MP层面和DP-manager的虚拟化管理。
在一种较佳的实施例中，所述的第一Docker容器对多个逻辑CPE设备的DP层面进行虚拟化管理，且所述的第一Docker容器绑定至被管理终端的网络接口；第二Docker容器对单个逻辑CPE设备的CP层面进行虚拟化管理，第三Docker容器对单个逻辑CPE设备的MP层面进行虚拟化管理，第四Docker容器对单个逻辑CPE设备的DP-manager进行虚拟化管理。在具体实施例中，“被管理终端”是一个功能简化的“瘦”版CPE，仅仅实现QinQ的外层VLAN或隧道端结功能，且每个逻辑CPE设备对应设置有一个第二Docker容器、第三Docker容器和第四Docker容器，多个逻辑CPE设备对应设置有一个第一Docker容器。
在一种更佳的实施例中，所述的第一Docker容器的数目为1个，所述的第二、第三和第四Docker容器的数目与该虚拟化管理系统中待管理的逻辑CPE设备的数目相一致。
在一种更佳的实施例中，所述的第一Docker容器和第四Docker容器均为申请有共享内存的Docker容器，且所述的第一Docker容器和第四Docker容器通过共享内存进行数据交流，且所述的第四Docker容器之间写互斥。
在一种较佳的实施例中，单个逻辑CPE设备的第二、第三和第四Docker容器之间通过配置管理桥相互连接，组成私有配置网络，且所述的第三Docker容器设置有对外服务端口以及北向配置管理接口。
在一种更佳的实施例中，还包括流量识别单元，与所述的网络接口连接，对流经网络接口的流量进行流量识别，判断流量所属的逻辑CPE设备。在具体实施例中，流量识别单元还将流量传输到对应的逻辑CPE设备。
基于Docker技术的逻辑CPE设备的虚拟化管理系统的配置方法，其主要特点是，所述的配置方法为：
将逻辑CPE设备的DP层面、CP层面、MP层面和DP-manage部署到对应的Docker容器中。
在一种更佳的实施例中，将逻辑CPE设备的DP层面、CP层面、MP层面和DP层面-manage部署到对应的Docker容器中时，包括以下步骤：
(1)将多个逻辑CPE设备的DP层面部署到第一Docker容器，并将所述的第一Docker容器绑定至被管理终端的网络接口；
(2)为所述的第一Docker容器申请共享内存，并对该第一Docker容器进行初始化；
(3)将DP-manager部署到第四Docker容器，为所述的第四Docker容器申请共享内存，并将第四Docker容器之间设置为写互斥；
(4)将逻辑CPE设备的CP层面、MP层面和DP层面-manage分别对应部署到第二、第三和第四Docker容器中。
在一种更佳的实施例中，所述的部署包括以下步骤：
(a)制作Docker容器的镜像配置文件Dockerfile，并制定Docker容器的参数；
(b)执行Docker镜像制作命令，根据所述的镜像配置文件Dockerfile生成Docker容器镜像。
在一种具体实施例中，本发明具有以下实施前提：
(1)物理网络口流入或流出的数据报文，通过已知技术手段进行逻辑CPE设备的归属识别；
(2)上述技术手段在逻辑CPE设备的上下游设备当中同样支持，即不存在互连互通问题。
在具体实施例中，逻辑CPE设备软件被预先部署在物理服务器或虚拟服务器上，对外呈现若干逻辑CPE设备，每个逻辑CPE设备均有四个实体或容器，即MP层面容器、CP层面容器、DP-manger容器、DP层面容器；其中DP层面容器为各逻辑CPE设备共享，在具体实施例中，网络规划人员还对不同的逻辑CPE设备进行配置，使之能够区分网络报文(即流量)的归属，所述的管理员或租户分别对逻辑CPE设备进行功能和策略配置。
随着DP层面dpdk、vpp技术的引入以及编排工具的进一步发展，将逻辑CPE设备的DP层面进一步的虚拟化成为可能，将多个逻辑CPE设备的DP层面部署到同一个Docker容器中也成为可能，且逻辑CPE设备的MP层面和CP层面可合二为一(统称为CP层面)，也可分开部署，在一种具体实施例中，MP层面和CP层面是分开部署的。由于逻辑CPE设备的MP层面和CP层面相对于DP层面而言，资源消耗要更小，且MP层面和CP层面需要承接大量的差异化配置及协议计算，因此，将MP层面和CP层面单独置于Docker容器内，MP层面的Docker容器与CP层面的Docker容器与逻辑CPE设备数量相同，MP层面、CP层面和逻辑CPE设备的数量应当是1:1:1。
请参阅图1，MP层面、CP层面以及DP-manager分别置于独立的Docker容器内，逻辑上分别形成彼此互相独立的逻辑CPE设备虚拟设备。Shared Memory和Fast-path/Slow-Path作为DP层面置于单独的容器内，为各个逻辑CPE设备虚拟机设备所共享。配置数据流包括用户配置的安全策略等；网络协议数据流包括用户上线的认证消息，路由协议报文等。配置数据流的承载网络采用虚拟网络，比如ovs等技术，网络协议数据流的承载网络在CP层面仍采用ovs等虚拟化技术，DP层面需要兼顾网络带宽和不同逻辑CPE设备流量的隔离，可采用DP层面dpdk技术，直接封装VLAN报文。图1中未标出用户的业务数据流向，这些数据直接在DP层面处理，或查路由、进行NAT转换等。
其中，MP、CP、DP-manager之间通过Publish/Subscribe传递配置、统计等信息；而DP-manager和Shared memory及Fast-path/Slow-path和Shared memory之间是配置、统计信息的直接读写。
且由于各逻辑CPE设备的物理网络口是共享的，因而需要使用辅助的技术手段，对归属不同逻辑CPE设备的流量(网络报文)进行区分识别。传统逻辑CPE设备更靠近终端用户，通常终端用户直接通过局域网与逻辑CPE设备互联，这种情况下，归属不同逻辑CPE设备的流量天然分离的，不存在区分一说。但是逻辑CPE设备功能虚拟化之后，终端用户与虚拟化逻辑CPE设备的距离拉远了，需要引入相关技术手段区分归属不同逻辑CPE设备虚拟设备的流量。这些辅助的技术手段有QinQ(双层vlan)、Vxlan、以及IpSec等隧道技术。
由于MP层面、CP层面、DP层面实质上分别是功能侧重点不同的一组进程，最彻底的做法是每个逻辑CPE设备都有互相独立的资源实例(MP层面、CP层面、DP层面)，这种情况下，某个逻辑CPE设备宕机，其它逻辑CPE设备实例理论上是不受影响的，这在技术上是完全可行的，但考虑到DP层面功能侧重转发功能，如果与逻辑CPE设备等量的DP层面方式部署，其对包括布线、承载带宽、物理服务器的资源占用势必引入相当大的代价，DP层面的物理单实例逻辑多实例的事实，使得理论上还是存在不同逻辑CPE设备实例间的互相影响的，但DP层面侧重业务转发而不是面临网络事件的复杂逻辑处理(这些由CP层面负责)。综合上述两点，使用本发明中的虚拟化管理系统时，当单个逻辑CPE设备宕机时，对其它逻辑CPE设备的影响是降到最低的。
制作容器的过程：
容器镜像制作：
(1)对每个类型的容器，分别制作Docker容器镜像配置文件Dockerfile，指定基础镜像、待安装的软件等；
(2)执行Docker镜像制作命令，生成容器镜像。具体实施时，通过可执行脚本，封装各类型容器镜像的制作过程，做到一键式镜像制作。
容器部署：
(1)优先部署DP层面容器。DP层面容器需要绑定物理网络接口(如果部署在虚拟机上，这里的物理网络接口即为用于用户数据通信的网络接口)，申请共享内存及必要的初始化工作。
(2)部署DP层面-manger容器。DP层面-manger容器通过共享内存向DP层面容器传送配置信息。此外，DP层面-manger容器保证与其它DP层面-manger容器间的写互斥。
(3)部署MP层面和CP层面容器。
配置：
(1)MP层面容器、CP层面容器、DP层面-manger容器通过配置管理桥组成私有配置网络；
(2)MP层面容器通过开放对外服务端口，提供北向配置管理接口。
用户网络服务过程：
(1)用户数据到达物理网络接口后，DP层面容器通过网络规划配置信息识别归属的逻辑CPE设备；
(2)DP层面容器、CP层面容器通过内部私有通信网络传递控制协议数据；
(3)DP层面容器根据与配置功能和策略信息以及动态配置信息完成用户数据的转发。
在具体实施例中，在用户侧，逻辑CPE设备负责用户子网划分以及终端用户的IP分配，比如DHCP协议，终端用户作为DHCP Client，逻辑CPE设备的CP层面作为DHCP Server。在网络侧或用户侧的隧道协议层面，逻辑CPE设备需要处理来自网络的ARP、路由等协议，这些协议控制报文也经该内部私有通道在DP层面与CP层面之间交换。DP层面容器根据配置功能和策略信息以及动态配置信息完成用户数据的转发。这里的配置功能通常包含NAT、VPN、DPI或者其它尚未开发的定制功能，策略信息指流量控制、安全策略或其它待开发的定制策略，动态配置信息指静态或动态路由配置。
采用本发明的基于Docker技术的逻辑CPE设备的虚拟化管理系统及其配置方法，通过Docker容器技术实现逻辑CPE设备逻辑层面间的隔离，通过基于Docker容器技术的多逻辑CPE设备解决不同用户的定制特性需求，通过DP层面物理单实例、逻辑多实例解决虚拟化设备资源消耗大及转发效率低问题，具有以下技术效果：(1)各逻辑CPE设备松耦合，策略和功能定制化；(2)单个逻辑CPE设备宕机，对其它逻辑CPE设备映像降到最低；(3)DP层面物理上单实例，逻辑上多实例，极大降低物理资源消耗；(4)物理网络口有限，布线简化。
在此说明书中，本发明已参照其特定的实施例作了描述。但是，很显然仍可以作出各种修改和变换而不背离本发明的精神和范围。因此，说明书和附图应被认为是说明性的而非限制性的。