DOCA Service

DOCA Service是基于DOCA的产品，封装在容器中，可以在NVIDIA®BlueField®DPU上快速轻松地部署。DOCA Service利用DPU功能提供遥测、时间同步、网络解决方案等。

请注意，以下服务在NGC目录中不提供:

l  DOCA管理服务

l  NVIDIA OpenvSwitch加速(OVS in DOCA)

开发生命周期

基于doca的容器包括两大类:

l  DOCA base image:用于运行时和开发的容器化DOCA环境。由开发人员用于其开发环境或在容器化基于doca的解决方案的过程中使用。

l  DOCA Service:基于DOCA的容器化产品。

开发

在将产品容器化之前，用户必须首先使用在BlueField DPU上进行裸金属部署的相同流程来设计和开发产品。这个过程包括以下步骤:

l  确定基于doca的解决方案的需求。

l  回顾DOCA SDK库提供的特性集，在各自的编程指南中有详细介绍。

l  按照我们的开发者指南开始开发过程，充分利用我们提供的技巧和工具。

l  测试开发的解决方案。

一旦开发的产品足够成熟，就是时候开始将其容器化了。

容器化

在这个过程中，建议使用DOCA提供的base image，可以在DOCA的NGC页面上找到。

提供三种image:

l  base-rt——包括DOCA运行时，使用DOCA SDK所需的最基本运行时环境

l  full-rt—构建在前一个映像上，并包含运行时包的完整列表，这些都是可以在doc -runtime包下找到的所有用户模式组件

l  devel——建立在前一个映像的基础上，并添加用于开发和调试DOCA应用程序的头文件和开发工具。此映像对于多阶段构建特别有用。

所有image都预先配置为用于匹配DOCA版本的DOCA存储库。这意味着在开发容器中安装额外的DOCA包作为Dockerfile /的一部分可以使用以下命令完成:

对于DOCA和CUDA环境，这些结合CUDA的image类似：

l  base-rt (DOCA) + base (CUDA)

l  full-rt (DOCA) + runtime (CUDA)

l  devel (DOCA) + devel (CUDA)

一旦容器化解决方案足够成熟，用户就可以开始分析它，为生产级部署做准备。

分析

当前DPU之上的容器部署模型是基于kubelet-standalone的，使用YAML文件来描述pod所需的资源，例如:

l  CPU

l  内存

l  巨页

需要对产品进行分析，估计所需的资源(在常规部署下，以及在压力测试下)，以便在YAML中指定准确的资源。确保管理员更好地了解部署服务的需求，并保证k8s基础设施确保服务在部署后不会出现错误行为。

一旦完成，基于doca的容器化产品就可以进行最后一轮测试，之后就可以在生产环境中部署了。

Services

DOCA BlueMan Service 

DOCA BlueMan Service在DPU中作为一个独立的web界面运行，并将所有基本信息、健康状况和遥测统计整合到一个界面中。

DOCA Firefly Service

DOCA Firefly Service为BlueField DPU提供基于PTP协议的时间同步服务。PTP用于同步网络中的时钟，当与硬件支持结合使用时，PTP能够达到亚微秒精度，这远远优于通常使用网络时间协议(NTP)获得的精度。

DOCA Flow Inspector

DOCA Flow Inspector允许监控实时数据和提取各种遥测数据，这些数据可用于各种安全、大数据等服务。DOCA Flow Inspector service连接到DOCA DTS，接收来自用户的镜像数据包，解析数据，并将其转发给DTS，DTS聚合来自各种提供者的预定义统计信息。该服务利用DOCA Telemetry Exporter API与DTS通信，而用户空间层获取数据包采用DPDK。

DOCA Flow Inspector在BlueField上的专用Kubernetes pod中运行，旨在接收镜像数据包进行分析。接收到的数据包在预定义的结构中被解析并传输到Telemetry收集器。

Service Flow

DOCA Flow Inspector接收JSON格式的配置文件，其中包括应该过滤哪些镜像数据包以及应该将哪些信息发送到DTS进行检查。

配置文件会包含几个"export-units"属性。每个"export-units"都由一个"filter"和一个 "export"组成。收到的报文会根据"filter"定义的规则进行匹配（L4 header中的protocol和port），匹配"filter"的报文会按照"export"定义的结构处理。不匹配任何"filter"的数据包将被丢弃。

此外，配置文件可以包含FI选项。

该服务在运行时会监视JSON配置文件的更改。

DOCA Flow Inspector运行在DPDK之上以获取L4报文。然后对数据包进行过滤，并使用其export units id进行HW标记。然后根据其export units定义的结构对数据包进行解析，然后使用IPC将其转发给Telemetry收集器。

l  配置阶段:

1.      使用JSON文件作为输入来配置export unit(即filter和相应的export struct)。

2.      使用DOCA Flow库将filter转换为SF(可扩展功能端口)上的HW规则。

3.      初始化到telemetry收集器的连接，并将所有export struct注册到DTS。

l  检查阶段:

1.      流量被镜像到相关的SF。

2.      SF接收Ingress流量。

3.      使用HW规则丢弃非L4流量和不匹配任何filter的数据包。

4.      与filter匹配的数据包被标记为对应的export unit id，并被传递到Arm cores中的软件层。

5.      数据包解析为export unit定义的结构。

6.      telemetry 信息通过IPC转发给telemetry 代理。

7.      镜像数据包被释放。

8.      如果JSON文件发生了变化，请使用更新后的文件重新运行配置阶段。

JSON文件

文件格式如下：

l  protocols取值范围：”TCP”、”UDP”；

l  ports取值范围：0-65535之间的任何端口，*代表任何端口，或者start_port-end_port指定的范围；

l  fields取值范围：

DOCA HBN

DOCA Host-Based Networking service编排在云服务器上动态创建的虚拟机/容器网络连接。HBN业务是一种BGP路由器，支持EVPN扩展，实现多租户云。

本质上，HBN是DPU的Linux网络加速驱动程序，netlink-to-DOCA daemon，这个守护进程使用DOCA api在BlueField硬件中编程特定的数据包处理规则，无缝地加速Linux网络。该驱动程序将Linux kernel routing和bridge tables镜像到BlueField硬件表中，linux协议栈的网络数据流也被编程到硬件中。

HBN各个组件之间的交付关系如下图所示：

l  ifupdown2是接口管理器，它将所有与接口相关的状态发送到内核；

l  路由栈在FRR中实现，并通过netlink将所有控制状态(EVPN mac和路由)发送到内核；

l  内核维护整个网络的状态，并通过netlink传递信息。内核还涉及到下注路径和处理不匹配eSwitch中任何规则的流量。

l  nl2docad通过netlink侦听网络状态，并调用DOCA接口来加速BlueField硬件表中的数据流。nl2docad还将这些流卸载到eSwitch。

DOCA Management Service

DOCA Management Service(DMS)是为用户配置和操作NVIDIA BlueField网络平台和NVIDIA ConnectX适配器(nic)提供的一站式服务。DMS通过OpenConfig社区创建的简单开放API管理NVIDIA的所有脚本/工具。用户可以为任何模式配置BlueField或ConnectX，不管是本地(ssh)或远程(grpc)。它可以很容易地迁移和引导任何NVIDIA网络设备。

DMS通过外部接口公开可配置的BlueField/ConnectX参数，以支持NVIDIA网络适配器自动化配置。公开的接口为BF/CX设备配置提供了统一的方法。

DMS是一个CS体系结构。使用守护进程处理资源的发现，并接收来自客户端的命令，用户可以使用DMS自带的DMSc (DMS client)，或者使用任何其他客户端。

部署

l  DMS有三个主要组件:

n  DMSD：Server - DMS服务器在BlueField或主机上；

n  DMSC：Client – DOCA提供的OpenConfig client。用户可以选择使用这个client、任何其他开源client，或者开发他们自己的(基于grpc的)client；

n  Yang文件：Yang文件用于配置BlueField设备的数据模型，OpenConfig Yang模型通用的配置文件；

l  OpenConfig包含两个主要协议:

n  gNMI：gRPC Network Management Interface，一种配置网络设备的协议。

n  gNOI：gRPC Network Operations Interface，一种在网络设备上执行操作命令的协议(例如，配置、升级、重启)；

OpenvSwitch加速(DOCA中的OVS)

OVS-DOCA是一种虚拟交换服务，设计用于NVIDIA网卡和DPU，利用ASAP2(Accelerated Switching and Packet Processing)技术进行数据路径加速，提供最佳的性能。

OVS (Open vSwitch)是一种基于软件的网络技术，用于增强虚拟机在内部网络和外部网络之间的通信。OVS通常部署在虚拟机管理程序中，采用基于软件的方法进行分组交换，这会导致CPU资源紧张，影响系统性能和网络带宽利用率。为了解决这个问题，NVIDIA的Accelerated Switching and Packet Processing(ASAP2)技术将OVS数据平面任务卸载到专门的硬件上，如网卡子系统中的嵌入式交换机(eSwitch)，同时保持未修改的OVS控制平面。这在不增加CPU负担的情况下显著提高了OVS性能。

NVIDIA的DOCA-OVS扩展了传统的OVS-DPDK和OVS-Kernel数据路径卸载接口(DPIF)，引入了OVS-DOCA作为额外的DPIF实现。DOCA-OVS基于NVIDIA的网络API，保留了与OVS-DPDK和OVS-Kernel相同的接口，同时利用了带有额外OVS-DOCA DPIF的DOCA Flow库。与使用其他DPIF (DPDK, Kernel)不同，OVS-DOCA DPIF利用独特的硬件卸载机制和应用程序技术，最大限度地提高NVDIA网卡和DPU的性能。由于其架构和DOCA库集成，这种模式特别高效，增强了e-switch配置，并加速了其他模式无法实现的硬件卸载。

OVS和虚拟化设备

当OVS与网卡和DPU(如NVIDIA®ConnectX®-6 Lx/Dx和NVIDIA®BlueField®-2等)结合使用时，数据平面采用ASAP2的硬件加速。该数据平面可以通过SR-IOV的VF或virtual host Data Path Acceleration (vDPA)的virtio与虚拟机建立连接。

在这两种情况下，网卡内的加速器引擎都可以加速OVS规则的转发和卸载。对于DPU(包括网卡子系统)，另一种虚拟化技术在DPU内实现了完全的虚拟仿真，使主机服务器能够作为软件虚拟设备与DPU通信。

当在SR-IOV虚拟功能(VF)上使用ASAP2数据平面时，VF直接传递给虚拟机，NVIDIA驱动程序在虚拟机内运行。

使用vDPA时，vDPA驱动程序允许虚拟机通过virtio建立连接。因此，数据平面在SR-IOV VF和虚拟机内的标准virtio驱动程序之间建立，而控制平面在主机上由vDPA应用程序管理。

DOCA Telemetry

DOCA Telemetry Service(DTS)从内置提供者和外部telemetry应用程序收集数据。提供者如下：

l  数据提供者：

n  sysfs

n  ethtool

n  tc(traffic control)

l  Aggregation提供者：

n  fluent_aggr

n  prometheus_aggr

DTS将收集到的数据存储到/opt/mellanox/doca/services/telemetry/data目录下的二进制文件中。由于BlueField存储限制，默认不允许数据写入。

DTS可以通过Prometheus Endpoint (pull)或Fluent Bit (push)导出数据。

当数据从DOCA Telemetry Exporters NetFlow API client收集时，DTS允许导出NetFlow数据包。通过在dts_config.ini中设置NetFlow采集器的IP/地址和端口，可以使能NetFlow exporter。

Service部署

DPU上默认会启用DTS，并作为BlueField image的一部分发布。

DPU部署

/etc/kubelet.d/ doc_telemetry_standalone .yaml指定DTS在BlueField引导时自动启动。删除.yaml文件将停止自动启动DTS。

DTS文件可以在/opt/mellanox/doca/services/telemetry/目录下找到，其下有三个目录：

l  config

l  data

l  ipc_sockets

host部署

DTS支持x86_64主机。provider和exporter都在单个docker容器上运行。

1.指定DTS image版本:

2.运行docker：

和Grafana一起部署

部署要求

l  BlueField DPU要运行DOCA Temetry Service；

l  可管理Grafana和Prometheus的远程服务器；

l  主机上安装Prometheu；

l  主机上安装Grafana；

Grafana部署配置

DPU端配置

使用Prometheus插件配置DTS来导出sysfs counter:

1.使能sysfs counter：

2.使能exporter：

3.重启DTS。

Prometheus 配置(Remote Server)

1.      安装Prometheus；

2.      打开Prometheus文件，配置DPU为endpoint target：

dpu-ip为DPU的IP地址，prometheus-port为在DTS配置文件中设置的端口。Prometheus连接这个IP来获取数据。

3.       运行Prometheus：

Grafana 配置(Remote Server)

1.      安装Grafana；

2.      请参考相关文档进行设置；

3.   登录Grafana管理界面，Grafana默认端口是3000；

设置Prometheus作为数据来源；

5.      设置Prometheus的URL地址，Prometheus默认端口是9090；

6.      操作界面，导出Telemetry数据

初始化脚本

l  /usr/bin/telemetry-init.sh：用于当config目录为空时，生成默认配置文件。

l  /usr/bin/enable-fluent-forward.sh：配置Fluent Bit转发的destination IP和port。该脚本会配置fluent_bit_configs目录下的.exp文件。

enable Fluent Bit转发

在.yaml文件的initContainers的命令行中添加destination IP和port:

恢复默认配置

删除配置文件并重启服务会重新生成默认配置。

enable provider

编辑dts_config.ini文件，如下图所示：

远程收集

由于各种限制，某些提供provider或组件无法在容器内执行。因此，它们必须远程执行。

启用远程收集步骤如下:

l  激活DOCA Privileged Executer(DPE)，因为DPE可以实现远程收集：

l  编辑dts_config.ini文件，在所有provider前添加grc，例如，下面这行配置hcaperf提供程序的远程收集:

enable数据写入

编辑dts_config.ini文件，取消注释，如下图所示：

非容器内运行的程序IPC配置

当开发和测试非容器DOCA Telemetry Exporter程序时，为了程序可以通过IPC与DTS进行通信，需要进行一些修改:

l  删除共享内存映射:telemetry-ipc-shm；

l  开启主机IPC: hostIPC；

provider

DTS支持通过sysf、ethtool和tc收集平台数据。Fluent和Prometheus aggregator 可以从其他应用程序收集数据。

Sysfs Counters List

l  sysfs提供程序有几个组件:ib_port, hw_port, mr_cache, eth, hwmon和bf_ptm。

当sysfs启用时，所有组件(除了bf_ptm)都是启用的:

l  也可以单独禁用某个组件：

Power Thermal Counters

bf_ptm组件远程收集BlueField-3 power thermal counters。默认关闭，可通过以下方式开启:

l  加载内核模块mlxbf-ptm:

l  使用远程收集启用组件:

DPE要先激活。

Ethtool Counters

ethtool counter是ethtool工具生成的counter列表，具体请参考ethtool工具。

Traffic Control Info

linux traffic control统计信息。

PPCC_ETH Provider

PCC算法相关的统计信息。

Fluent Aggregator

fluent_aggr接收 Fluent Bit Forward报文，分析处理后转发到DTS。默认监听端口是42442，可以通过以下选项更改：

Prometheus Aggregator

prometheus_aggr从Prometheus endpoint轮询接收数据，聚合后的数据被转发到DTS。

每个endpoint按照以下格式指定：

network interface

通过ifconfig收集网口数据，使能：

HCA Performance

hcaperf收集HCA性能数据。因为它需要访问RDMA设备，所以它必须在DPU上使用远程收集。在主机上，用户以特权模式和RDMA设备挂载的方式运行容器。counter是和具体设备相关的。

l  在DPU上使能hcaperf远程收集，如下图所示：

l  在host上使能hcaperf：

NVIDIA System Management Interface

nvdia-smi通过NVIDIA system management interface收集GPU相关信息。

NVIDIA Data Center GPU Manager

dcgm收集由NVIDIA data center GPU manager (DCGM) API提供的GPU信息。

BlueField Performance

bfperf收集BlueField Arm cores的计算性能计数器。使能bfperf如下图所示：

Ngauge

Ngauge收集网络接口卡(nic)诊断数据。

数据输出

DTS可以将收集到的数据发送到以下目的地:

l  写入磁盘(以二进制形式保存)；

l  Fluent BitPrometheus endpoint；

DOCA UROM

DOCA UROM service提供了一个框架，可以将HPC软件栈的重要部分直接从主机卸载到BlueField设备。

该服务使用守护进程处理资源的发现、主机和BlueField之间的协调，以及BlueField worker本身的创建、管理和销毁。

启动卸载的第一步需要UROM主机应用程序建立与UROM服务的连接。在收到plugin discovery命令后，UROM服务向应用程序响应一个BlueField上可用plugin列表。然后，应用程序将plugin id关联到它们的网络标识符。最后，该服务触发plugin id指定的UROM worker来执行并行计算任务。在服务的Kubernetes pod中，daemon负责创建worker。

需求

在部署UROM业务容器之前，需要满足以下前提条件:

根据DOCA的需要分配巨页:

或

plugin discovery and report

当应用程序发起到DOCA UROM Service的连接请求时，daemon读取UROM_PLUGIN_PATH环境变量。该变量指定plugin的.so文件的路径，多个路径用分号分隔。daemon依次扫描这些路径，并尝试加载每个.so文件。一旦daemon完成扫描，它就会向主机应用程序报告可用的BlueField plugin。

daemon报告的plugin列表格式如下：

Loading Plugin in Worker

在UROM daemon创建UROM worker期间，daemon在worker命令行中指定了plugin的列表。每个plugin以so_path:id的格式传递。

worker会遍历所有.so文件，并尝试通过使用dlopen系统调用来加载它们，并查找urom_plugin_get_iface()符号来获取plugin操作接口。

Yaml文件

命令行参数和环境变量也可以通过写入yaml配置文件，例如：

l  SERVICE_ARGS是运行时需要的参数：

n  -l, --log-level设置程序的log级别，10=DISABLE, 20=CRITICAL, 30=ERROR, 40=WARNING, 50=INFO, 60=DEBUG, 70=TRACE；

n  --sdk-log-level设置sdk的log级别，10=DISABLE, 20=CRITICAL, 30=ERROR, 40=WARNING, 50=INFO, 60=DEBUG, 70=TRACE；

n  -m, --max-msg-size设置通信通道的报文大小；

l  UROM_PLUGIN_PATH指定plugin .so文件路径；

对于BlueField上的每个plugin，都需要在服务容器中添加挂载点。例如: