目录
一、概述
二、完整QoS策略文件
三、简化QoS策略定义
四、策略文件语法规则
五、完整策略文件示例
六、简化的QoS策略
6.1 IPoIB
6.2 SDP
6.3 RDS
6.4 iSER
6.5 SRP
6.6 MPI
七、SL2VL映射和VL仲裁
缩写 | 全拼 | 中文 |
---|---|---|
SM | Subnet Manager | 子网管理器(实体) |
SA | Subnet Administrator | 子网管理(接口) |
QoS | Quality of Service | 服务质量 |
PR | PathRecord | 路由记录 |
MPR | MultiPathRecord | 多播路由记录 |
ULP | Upper Layer Protocol | 上层协议 |
SL | Service Level | 服务级别 |
VL | Virtual Lanes | 虚通道 |
PKey | Partition Key | 分区键 |
QoS的诉求来源于IB网络需要实现IB网络I/O的访问。由于多个应用程序和ULP共享同一组网,因此需要一种方法来控制它们对网络资源的使用。
基本诉求是给不同业务流提供的不同服务级别,以便可以执行策略,以此来控制组网资源的每个流利用率。
InfiniBand体系结构规范定义了几个支持QoS的硬件功能和管理接口:
多达15条虚通道(VL)以非阻塞方式承载流量:
OpenSM使能的时候,会去寻找QoS策略文件。默认路径为/usr/local/etc/opensm/qos-policy.conf。
当组网部署过程中,每一次扫描发现新的设备时,OpenSM都会解析QoS策略文件并把它部署上去,然后每一个客户端请求都会强制执行这个提供的QoS策略。此类请求的总体流程是:
有两种方法去定义QoS策略。
虽然完整的策略语法非常灵活,但在许多情况下简化的 策略定义就足够了。
QoS策略文件包含以下部分:
1.端口组。
本节定义了零个或多个端口组,这些端口组可以通过以下匹配规则描述:
2.QoS设置
本节介绍如何在组网的各个节点上设置SL2VL和VL仲裁表。
但是,OpenSM目前不支持此功能。
SL2VL和VLArb表应在OpenSM选项文件中配置。(默认位置-/usr/local/etc/opensm/opensm.conf)
3.QoS级别
每个QoS级别定义SL和一些可选字段:
当执行路径搜索时,必须按照QoS级别参数施加的限制进行搜索。必须定义一个DEFAULT QoS级别,PR/MPR查询匹配不上任何策略时应用。类似于任何其他QoS级别,它也可以由任何匹配规则显式引用。
4.QoS匹配规则(由QoS匹配规则表示)。
OpenSM接收到的每个PR/MPR查询都根据一组匹配规则进行匹配。按照QoS策略文件中出现的顺序扫描规则,例如第一个匹配优先。
每个规则都有一个QoS级别的名称。
默认QoS级别应用于与任何规则都匹配不上的查询。
查询可以通过以下方式进行匹配:
若要匹配某个匹配规则,PR/MPR查询必须匹配规则的所有条件。但是,并不是PR/MPR查询的所有字段都必须出现在匹配规则中。例如,如果规则只有一个条件——服务ID,那么它将匹配具有该服务ID的任何查询,而不考虑其他查询字段。但是,如果某个查询只有服务ID(这意味着这是PR/MPR组件掩码中唯一打开的位),则它将不匹配除服务ID之外还有其他匹配条件的任何规则。
简化QoS策略定义由qos-ulps单个部分表示的。与完整QoS策略类似,它有一个匹配规则及其QoS级别的列表,但在这种情况下,匹配规则只有一个标准-其目标是匹配某个ULP(或该ULP之上的某个应用程序)PR/MPR请求,而QoS级别只有一个约束-SL。
简化策略部分可以与完整策略一起出现在策略文件中,也可以作为独立的策略定义出现。
请参阅以下匹配规则条件的详细信息和列表。
如前所述,策略文件的任何部分都是可选的,并且策略文件的唯一强制部分是默认QoS级别。
以下是最短策略文件的示例:
qos-levels
qos-level
name: DEFAULT
sl: 0
end-qos-level
end-qos-levels
缺少端口组部分,因为没有匹配规则,这意味着端口组不会被引用到任何地方,也不需要定义它们。由于此策略文件没有任何匹配规则,PR/MPR查询将不匹配任何规则,并且OpenSM将强制执行默认的QoS级别。
从本质上讲,上述示例相当于根本没有QoS策略文件。
以下示例显示了策略文件及其语法:
#
# See the comments in the following example.
# They explain different keywords and their meaning.
#
port-groups
port-group # using port GUIDs
name: Storage
# "use" is just a description that is used for logging
# Other than that, it is just a comment
use: SRP Targets
port-guid: 0x10000000000001, 0x10000000000005-0x1000000000FFFA
port-guid: 0x1000000000FFFF
end-port-group
port-group
name: Virtual Servers
# The syntax of the port name is as follows:
# "node_description/Pnum".
# node_description is compared to the NodeDescription of the node,
# and "Pnum" is a port number on that node.
port-name: vs1 HCA-1/P1, vs2 HCA-1/P1
end-port-group
# using partitions defined in the partition policy
port-group
name: Partitions
partition: Part1
pkey: 0x1234
end-port-group
# using node types: CA, ROUTER, SWITCH, SELF (for node that runs SM)
# or ALL (for all the nodes in the subnet)
port-group
name: CAs and SM
node-type: CA, SELF
end-port-group
end-port-groups
qos-setup
# This section of the policy file describes how to set up SL2VL and VL
# Arbitration tables on various nodes in the fabric.
# However, this is not supported in OpenSM currently - the section is
# parsed and ignored. SL2VL and VLArb tables should be configured in the
# OpenSM options file (by default - /usr/local/etc/opensm/opensm.conf).
end-qos-setup
qos-levels
# Having a QoS Level named "DEFAULT" is a must - it is applied to
# PR/MPR requests that didn't match any of the matching rules.
qos-level
name: DEFAULT
use: default QoS Level
sl: 0
end-qos-level
# the whole set: SL, MTU-Limit, Rate-Limit, PKey, Packet Lifetime
qos-level
name: WholeSet
sl: 1
mtu-limit: 4
rate-limit: 5
pkey: 0x1234
packet-life: 8
end-qos-level
end-qos-levels
# Match rules are scanned in order of their appearance in the policy file.
# First matched rule takes precedence.
qos-match-rules
# matching by single criteria: QoS class
qos-match-rule
use: by QoS class
qos-class: 7-9,11
# Name of qos-level to apply to the matching PR/MPR
qos-level-name: WholeSet
end-qos-match-rule
# show matching by destination group and service id
qos-match-rule
use: Storage targets
destination: Storage
service-id: 0x10000000000001, 0x10000000000008-0x10000000000FFF
qos-level-name: WholeSet
end-qos-match-rule
qos-match-rule
source: Storage
use: match by source group only
qos-level-name: DEFAULT
end-qos-match-rule
qos-match-rule
use: match by all parameters
qos-class: 7-9,11
source: Virtual Servers
destination: Storage
service-id: 0x0000000000010000-0x000000000001FFFF
pkey: 0x0F00-0x0FFF
qos-level-name: WholeSet
end-qos-match-rule
end-qos-match-rules
简化的QoS策略匹配规则是为匹配ULP(或ULP之上的一些应用程序)PR/MPR请求而定制的。本节列出了每个ULP(或每个应用程序)的匹配规则以及应在匹配的PR/MPR查询上强制执行的SL。
匹配规则包括:
由于策略文件的任何部分都是可选的,只要保留文件的基本规则(例如不引用不存在的端口组、具有默认QoS级别等),简化的策略部分(QoS ulps)就可以作为一个完整的QoS策略文件。
在这种情况下,最短的策略文件如下:
qos-ulps
default : 0 #default SL
end-qos-ulps
它相当于前面的最短策略文件示例,也相当于根本没有策略文件。
下面是一个简化的QoS策略示例,包含所有可能的关键字:
qos-ulps
default : 0 # default SL
sdp, port-num 30000 : 0 # SL for application running on top
# of SDP when a destination
# TCP/IPport is 30000
sdp, port-num 10000-20000 : 0
sdp : 1 # default SL for any other
# application running on top of SDP
rds : 2 # SL for RDS traffic
iser, port-num 900 : 0 # SL for iSER with a specific target
# port
iser : 3 # default SL for iSER
ipoib, pkey 0x0001 : 0 # SL for IPoIB on partition with
# pkey 0x0001
ipoib : 4 # default IPoIB partition,
# pkey=0x7FFF
any, service-id 0x6234 : 6 # match any PR/MPR query with a
# specific Service ID
any, pkey 0x0ABC : 6 # match any PR/MPR query with a
# specific PKey
srp, target-port-guid 0x1234 : 5 # SRP when SRP Target is located on
# a specified IB port GUID
any, target-port-guid 0x0ABC-0xFFFFF : 6 # match any PR/MPR query with
# a specific target port GUID
any, source-port-guid 0x5678 : 7 # match any PR/MPR query with
# a specific source port
# GUID
any, source-target-port-guid 0x9abcd : 8 # match any PR/MPR query with
# a specific source or target port
# GUID
end-qos-ulps
与完整的策略定义类似,PR/MPR查询的匹配是按照QoS策略文件中出现的顺序进行的,例如第一个匹配优先,但“默认”规则除外,该规则仅在查询与任何其他规则不匹配时应用。
QoS策略文件的所有其他部分优先于qos-ulps部分。也就是说,如果策略文件同时具有qos-match-rules和qos-ulps部分,则任何查询都将首先与qos-match-rules相匹配,并且只有在没有匹配的情况下,才与qos-ulps中的规则进行匹配。
请注意,这些匹配规则中的一些可能重叠,因此为了有效地使用简化的QoS定义,了解每个ULP是如何匹配的很重要:
IPoIB查询由PKey匹配。IPoIB分区的默认PKey为0x7fff,因此以下三个匹配规则是等效的:
ipoib :
ipoib, pkey 0x7fff :
any, pkey 0x7fff :
SDP PR 查询是匹配Service ID. SDP的Service-ID是
0x000000000001PPPP, 其中PPPP是4个十六进制数字,用于保存要连接的远程TCP/IP端口号. 以下两个匹配规则是等效的:
sdp :
any, service-id 0x0000000000010000-0x000000000001ffff :
与SDP类似,RDS PR查询由Service ID匹配。RDS的Service ID是0x000000000106PPP,其中PPPP是4个十六进制数字,用于保存远程TCP/IP要连接的端口号。RDS的默认端口号为0x48CA,这使得默认服务ID 0x00000000010648CA。以下两条匹配规则是等效:
rds :
any, service-id 0x00000000010648CA :
与RDS类似,iSER查询由服务ID匹配,其中服务ID也是0x000000000106PPP。iSER的默认端口号为0x0CBC,这使得默认服务ID为0x0000000001060CBC。以下两个匹配规则是等效的:
iser :
any, service-id 0x0000000001060CBC :
SRP的服务ID因存储供应商而异,因此SRP查询与目标IB端口GUID匹配。以下两个匹配规则是等效的:
srp, target-port-guid 0x1234 :
any, target-port-guid 0x1234 :
请注意,上述任何ULP都可能在PR查询中包含目标端口GUID,因此为了使这些查询不被QoS管理器识别为SRP,SRP匹配规则(或仅引用目标端口GUID的任何匹配规则)应放在QoS ULPs匹配规则的末尾。
MPI的SL由MPI管理员手动配置。OpenSM没有在MPI流量上强制使用任何SL,这就是为什么它是唯一一个没有出现在qos-ulps部分中的ULP。
OpenSM缓存选项文件有一组与QoS相关的配置参数,用于配置IB端口上的SL2VL映射和VL仲裁。
这些参数是:
- Max VLs: 子网上的最大VL数。
- High limit: VL仲裁表的高优先级组件的限制(IBA 7.6.9).
- VLArb low table: 低优先级VL仲裁表(IBA 7.6.9)模板.
- VLArb high table: 高优先级VL仲裁表(IBA 7.6.9)模板.
- SL2VL: SL2VL映射表(IBA 7.6.6)模板。它是对应于SL 0-15的VL的列表(注意,这里使用的VL15意味着丢弃该SL)。
对于各种目标类型,有单独的QoS配置参数集:
CA、路由器、交换机外部端口和交换机的增强端口0。这些参数的名称以“qos_
qos_ca_—为ca设置的qos配置参数。
qos_rtr-为路由器设置的参数。
qos_sw0_-为交换机端口0设置的参数。
qos_swe_-为交换机的外部端口设置的参数。
以下是CA和交换机外部的典型默认值示例端口(在OpenSM初始化中硬编码):
qos_ca_max_vls 15
qos_ca_high_limit 0
qos_ca_vlarb_high 0:4,1:0,2:0,3:0,4:0,5:0,6:0,7:0,8:0,9:0,10:0,11:0,12:0,13:0,14:0
qos_ca_vlarb_low 0:0,1:4,2:4,3:4,4:4,5:4,6:4,7:4,8:4,9:4,10:4,11:4,12:4,13:4,14:4
qos_ca_sl2vl 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,7
qos_swe_max_vls 15
qos_swe_high_limit 0
qos_swe_vlarb_high 0:4,1:0,2:0,3:0,4:0,5:0,6:0,7:0,8:0,9:0,10:0,11:0,12:0,13:0,14:0
qos_swe_vlarb_low 0:0,1:4,2:4,3:4,4:4,5:4,6:4,7:4,8:4,9:4,10:4,11:4,12:4,13:4,14:4
qos_swe_sl2vl 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,7
VL仲裁表(高和低)是VL/权重对的列表。
每个列表条目包含一个VL数(0-14的值)和一个加权值(0-255的值),指示当该VL在仲裁中发生时可以从该VL发送的64字节单元(信用)的数量。权重为0表示应跳过此条目。如果为VL15或端口不支持或当前未配置的VL编程了列表条目,则端口可以跳过该条目或从任何支持的VL发送该条目。
注意,相同的VL可以在高优先级仲裁表或低优先级仲裁表中多次列出,而且,它可以在两个表中都列出。
高优先级VLArb表的限制(qos_
high_limit值为255表示字节限制是无限制的。
注意:如果使用255值,则低优先级VL可能会被耗尽。值0表示在机会被给予低优先级表之前只能发送来自高优先级表的单个分组。
请记住,端口通常传输数据包大小等于MTU。
例如,对于4KB MTU,单个分组将需要64个信用,因此为了实现4KB MTU分组的有效VL仲裁,每个VL的加权值应该是64的倍数。
以下是子网上SL2VL和VL仲裁配置的示例:
qos_ca_max_vls 15
qos_ca_high_limit 6
qos_ca_vlarb_high 0:4
qos_ca_vlarb_low 0:0,1:64,2:128,3:192,4:0,5:64,6:64,7:64
qos_ca_sl2vl 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,7
qos_swe_max_vls 15
qos_swe_high_limit 6
qos_swe_vlarb_high 0:4
qos_swe_vlarb_low 0:0,1:64,2:128,3:192,4:0,5:64,6:64,7:64
qos_swe_sl2vl 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,7
在本例中,子网上配置了8个VL:VL0到VL7。VL0被定义为高优先级VL,并且在单个传输突发中被限制为6 x 4KB=24KB。这样的配置将适合需要低延迟并且在传输分组时使用小MTU的VL。其余的VL被定义为具有不同权重的低优先级VL,而VL4被有效地关闭。
参考资料:
1.OpenSM源码
2.QoS - Quality of Service - MLNX_OFED v5.6-1.0.3.3 - NVIDIA Networking Docs
3.NVIDIA MLNX-OS User Manual v3.10.6004