技术文档 Archives - 星融元Asterfusion

技术手册- 显示拥塞通知ECN

工作原理

ECN需要主动队列管理AQM策略结合才能发挥作用。路由器在队列溢出前检测到拥塞，在IP报头中设置Congestion Experienced (CE) Codepoint代码点来指示正在发生拥塞。

IP层对ECN的支持

在网络层一个发送主机必须能够表明自身能支持ECN与否，路由器在转发时必须能够表明它正在经历拥塞。ECN 使用 IPv4 首部或 IPv6 首部中 ToS (Type of Service，位于首部第 9 到 16 比特位) 字段的两个最低有效位（最右侧的位编码）来表示四个状态码。

IP 报文头部中的DSCP 字段有2 Bit 用于标识ECN。这2 个Bit 分别是：ECT（ECN Capable Transport）用来标识发送端设备是否支持ECN功能和CE（Congestion Experienced）用于标识报文在传输路径上是否经历过拥塞。

图1：IP Header中的ECN Bit

当ECT为0，CE为0时，表示IP报文不支持ECN
当ECT为0，CE为1时，表示IP报文支持ECN
当ECT为1，CE为0时，表示IP报文支持ECN
当ECT为1，CE为1时，表示IP报文支持ECN，且发生了拥塞

当两端支持 ECN 时，它将数据包标为 ECT(0) 或 ECT(1)。如果分组穿过一个遇到阻塞并且相应路由器支持 ECN 的活动队列管理（AQM）队列，它可以将代码点更改为CE而非丢包。这种行为就是“标记”，其目的是通知接收端即将发生拥塞。在接收端，该拥塞指示由上层协议（传输层协议）处理，并且需要将信号回传给发送端，以通知其降低传输速率。

因为 CE 指示只能由支持它的上层协议有效处理，ECN 只能配合上层协议使用。例如 TCP 协议，它支持阻塞控制并且有方法将 CE 指示回传给发送端。

IP层ECN报文交互

ECN 是报文在网络设备出口发生拥塞时，将使能ECN（当IP 报文的ECN 字段为01 或10，表示使能ECN）的IP 报文头部的ECN 字段标记ECN=11，表示该IP 报文遇到网络拥塞，且该IP 报文不会被WRED 机制丢弃。如果接收服务器发现IP 报文的ECN 字段被标记成11，就立刻产生CNP 拥塞通知报文，并将该报文发送带源服务器，CNP 消息里包含了拥塞的数据流信息，远端服务器接收到后，通过降低相应的数据流发送速率，环节网络设备拥塞，从而避免发生丢包。

发送端发送IP 报文标记ECN(ECN=10)
交换机在队列拥塞的情况下收到该报文，将ECN 字段修改为11 并转发出去
接收服务器收到ECN 为11 的报文发送拥塞，正常处理该报文
接收端产生拥塞通告，周期发送CNP（Congestion Notification Packets）报文，ECN字段为01，要求报文不能被网路丢弃
交换机收到CNP 报文后正常转发该报文
发送服务器收到ECN 标记为01 的CNP 报文解析后对相应的数据流限速算法

CNP报文格式

CNP作为拥塞控制报文，也会存在延迟和丢包，从发送端到接收端经过的每一跳设备、每一条链路都会有一定的延迟，会最终加大发送端接收到CNP的时间，而与此同时交换机端口下的拥塞也会逐步增多，若发送端不能及时降速，仍然可能造成丢包。建议拥塞通告域的规模不要过大，从而避免因为ECN控制报文交互回路的跳数过多，而影响发送端无法及时降速，造成拥塞。

图3：CNP协议报文格式

TCP层对ECN的支持

TCP支持使用TCP头中的三个标记来支持ECN。第一个标记是随机和（Nonce Sum，简称NS），用于防止TCP发送者的数据包标记被意外或恶意改动。另两位用于回传拥塞指示和确认接收到了拥塞指示回应。这即是ECN-Echo（ECE）和Congestion Window Reduced（CWR）位，图4为TCP Header中的CWR和ECE flag。

图4：TCP Header中的CWR和ECE flag

TCP SYN握手包会包含两个额外的flag： ECN-echo(ECE)和Congestion Window Reduced (CWR) 。这样双方就可以协商在数据传输期间是否可以正确的处理设置了CE位的数据包。
发送方在所有发送的数据包中设置ECN Capable Transport (ECT) 位。
如果发送方收到一个TCP数据包，报头中设置了ECE flag，则发送方将调整其拥塞窗口，就像它从丢失的数据包中快速恢复一样。发送方下一个数据包设置CWR flag，向接收方表明它已对拥塞做出反应。发送方在每个RTT间隔最多做出一次这种反应。
当接收方接收到设置了CE 位的数据包时，接收方将在所有数据包中设置 ECE flag。这将一直持续到它收到一个设置了CWR flag的数据包，表明发送方已经对拥塞做出了反应。 ECT 标志仅在包含数据有效载荷的数据包中设置。发送不包含数据有效载荷的 TCP ACK 数据包时，应清除 ECT 位。

TCP层ECN报文交互

当在一个TCP连接上协商ECN后，发送方指示连接上的TCP段携带IP分组传输流量，将支持ECN的传输用ECT码点标记。这使支持ECN的中间路由器可以标记具有CE码点的IP分组而不是丢弃它们，以指示即将发生的阻塞。

当接收到具有遇到阻塞码点时，TCP接收者使用TCP头中的ECE标记回传这个阻塞指示。当一个端点收到TCP带有ECE位的段时，它减少其拥塞窗口来代替丢包。然后，它设置段的CWR位来确认阻塞指示。节点保持传输设置有ECE位的TCP段，直到它接收到设置有CWR的段。

图5：TCP层ECN报文交互示意图

发送端主机发送Segment 1-5到接收端，这些Segment全部都设置了ECT
Segment 2由遇到阻塞的支持ECN的路由器转发，路由器将IP头设置CE代码点，这里检测到拥塞后的策略并不是直接丢弃数据包
接收端收到Sgement 2后，它会发送带有ECE flag的ACK
交换机收到报文后正常转发该报文
发送端收到带有ECE flag的第一个ACK时，它会降低其传输速率并发送带有CWR flag的下一个Segmemt 6，就好像检测到了丢包一样。同时接收端收到Segment 6后，因为已经解除拥塞所以发送的后续ACK将清除ECE flag

两个ECT Codepoints机制

在RFC2481中，ECN字段被分为ECN-Capable Transport(ECT) bit和CE bit。ECT对应着ECT(0) codepoint。ECT(1)在RFC2481中没有定义，所以在只支持单个ECT codepoint的时候，应该使用ECT(0)。
在RFC3168中，两个ECT codepoint的主要动机是提供一位ECN nouce随机数，路由器在设置CE codepoint时必须“擦除”这个随机数(擦除 CE codepoint的路由器在重建原始随机数时将面临额外的困难，因此终端节点更有可能检测到CE codepoint的重复擦除)。ECN nouce允许为发送方提供一种机制，验证网络元素没有擦除掉CE，并且接收方正确地向发送方报告接收到了带有CE codepoint的数据包。
发送方检测有缺陷网络元素的另一种方法是不定期的发送CE codepoint数据包，以查看接收方是否报告接收到。如果这些数据包在网络中遇到拥塞，路由器可能不会更改数据包，因为 CE codepoint已经设置，所以发送方无法确定路由器是否打算在这些数据包中设置 CE codepoint。并且与ECN随机数相比，对有缺陷网络元素和接收器的检查效率较低。
TCP设置ECN的规则
如果Host收到过ECN-setup SYN packet，那么它才能发送ECN-setup SYN-ACK packet
Host不能在packet上设置ECT，除非它已发送过ECN-setup SYN或ECN-setup SYN-ACK packet，并且已收到过ECN-setup SYN或ECN-setup SYN-ACK packet，并且没有发送过non-ECN-setup SYN 或non-ECN-setup SYN-ACK packet
如果Host收到过non-ECN-setup SYN或non-ECN-setup SYN-ACK packet，则它不应在packet上设置 ECT
如果Host曾在packet上设置ECT，则它必须正确设置/清除连接中所有后续packet中的CWR TCP bit
如果Host发送过ECN-setup SYN 或 ECN-setup SYN-ACK packet，并且没有收到 non-ECN-setup SYN 或 non-ECN-setup SYN-ACK packet。那么如果Host收到ECT 和CE设置了的packet，那么它必须按照支持ECN连接指定的方式处理这些packet
Host如果不愿意在TCP连接上使用ECN，则它应该清除packet中的ECE和CWR标志
Host不能在SYN 或SYN-ACK packet上设置 ECT

Fast ECN

当交换机队列中缓存数据包超过ECN阈值时，交换机会将拥塞信息标记报文的ECN字段，并携带到发送端服务器以通知其网络拥塞。接收端服务器接收到带有ECN字段的数据包后，发送CNP通知发送端服务器调整发送速率。

图6：传统ECN处理机制

如上图所示，当数据报文进入队列排队时，传统的显式拥塞通知（ECN）判断队列使用的缓存是否超过ECN阈值。如果超过ECN阈值，交换机将数据报文IP头部中的ECN字段标记为11。发送端服务器接收带有ECN字段标记的数据报文的时间为交换机队列的数据包转发时间加上网络中标记的数据包转发时间。如果网络存在严重的网络拥塞，则ECN的反馈不及时可能会加剧队列拥塞。

图7：Fast ECN处理机制

Fast ECN通过在数据报文出队列时，标记数据报文的ECN字段，从而缩短了入队列标记ECN的数据包转发时延，接收端服务器可以在最小的时延接收到ECN标记的数据报文，从而加快发送端速率的调整。

配置实例

网络拓扑

图8：ECN物理网络拓扑

服务器端配置

Server1

[root@server1 ~]# modprobe 8021q
[root@server1 ~]# vconfig add ens1f3 100
[root@server1 ~]# ifconfig ens1f3.100 1.1.1.2/24 up
[root@server1 ~]# route add -net 1.1.0.0 netmask 255.255.0.0 gw 1.1.1.1

Server2

[root@server2 ~]# modprobe 8021q
[root@server2 ~]# vconfig add ens1f3 200
[root@server2 ~]# ifconfig ens1f3.200 1.1.2.2/24 up
[root@server2 ~]# route add -net 1.1.0.0 netmask 255.255.0.0 gw 1.1.2.1

交换机端配置

配置CISCO-LIKE命令行

在交换机配置时，需要先配置CLI模式。然后进入CISCO-LIKE视图，使用CISCO-LIKE命令行进行配置操作。

admin@sonic:~$ sudo config cli-mode cli
admin@sonic:~$ sudo sonic-cli
sonic#

交换机A

sonic# configure terminal
sonic(config)# vlan 100
sonic(config)# vlan 200
sonic(config)# interface ethernet 0/9
sonic(config-if-0/0)# switchport trunk vlan 100
sonic(config)# interface ethernet 0/10

发送流量包

sonic(config-if-0/0)# switchport trunk vlan 200
sonic(config)# interface vlan 100
sonic(config-vlanif-100)# ip address 1.1.1.1/24
sonic(config)# interface vlan 200
sonic(config-vlanif-100)# ip address 1.1.2.1/24

Server1和Server2配置了Mellanox网卡，在Server2建立服务端，Server1建立客户端发送IB流量。

Server2：
[root@server3 ~]# ib_send_bw -R -x 5 -d mlx5_0 -F –report_gbits -f 2 -D 800 -S 3
Server1：
[root@server1 ~]# ib_send_bw -R -x 5 -d mlx5_0 -F –report_gbits -f 2 -D 800 -S 3 1.1.2.2 -T 12

交机限速

对交换机A出口做端口限速处理，发包时容易产生拥塞。

sonic# configure terminal
sonic(config)# policy-map table-policy
sonic(config-pmap-table-policy)# port-shape 8000000 12800
sonic(config)# interface ethernet 0/10
sonic(config-if-0/4)# service-policy table-policy

观察拥塞情况

交换机A

观察交换机A出口的拥塞情况，可以看到在限速的情况下发IB流量包，交换机A出口没有配置ECN的情况下发生了拥塞

sonic# show counters queue 0/10

Server1

观察服务器Server1的IB发包带宽, 可以看到服务器Server1在没有配置ECN发生拥塞的情况下，发包的平均带宽为4.59Gb/s。
[root@serveer1 ~]# ib_send_bw -R -x 5 -d mlx5_0 -F –report_gbits -f 2 -D 800 -S 3 1.1.5.2

配置交换机ECN功能

交换机A

sonic# configure terminal
sonic(config)# wred ecnname
sonic(config-wred-ecnname)# mode ecn gmin 15000 gmax 150000\
gprobability 20
sonic(config)# class-map ecn1
sonic(config-cmap-ecn)# match cos 0
sonic(config)# policy-map ecn2
sonic(config-pmap-enc2)# class ecn1
sonic(config-pmap-enc2)# wred ecnname
sonic(config)# interface ethernet 0/9
sonic(config-if-0/9)# service-policy ecn2
sonic(config)# interface ethernet 0/10
sonic(config-if-0/10)# service-policy ecn2

Server1

[root@Server1 ~]# echo 1 > /proc/sys/net/ipv4/tcp_ecn
[root@Server1 ~]# cma_roce_mode -d mlx5_0 -p 1 -m 2

Server2

[root@Server2 ~]# echo 1 > /proc/sys/net/ipv4/tcp_ecn
[root@Server2 ~]# cma_roce_mode -d mlx5_1 -p 1 -m 2
[root@Server2 ~]# echo 41 > /sys/class/net/enp2s0f1/ecn/roce_np/cnp_dscp

观察ECN功能

清空流量包计数

清空交换机A的流量包计数。

sonic# clear counters queue
Clear saved counters

发送IB流量

Server1和Server2配置了Mellanox网卡，在Server2建立服务端，Server1建立客户端发送IB流量。
Server2：[root@server3 ~]# ib_send_bw -R -x 5 -d mlx5_0 -F –report_gbits -f 2 -D 800 -S 3
Server1：
[root@server1 ~]# ib_send_bw -R -x 5 -d mlx5_0 -F –report_gbits -f 2 -D 800 -S 3 1.1.2.2 -T 128

交换机A

观察交换机A入口是否收到CNP的返回流量，cnp_dscp的值设置为41，对应通道UC5。
同时观察交换机A出口的拥塞丢包情况。

sonic# show counters queue 0/10

sonic# show counters queue 0/9

Server1

同时观察到交换机A出口配置ECN的情况下拥塞几乎消失，交换机A入口的队列5收到了CNP的返回流量。Server1发包的平均带宽为5.9Gb/s。

[root@server1 ~]# ib_send_bw -R -x5 -d mlx5_1 -F –report_gbits –rate_limit=100 -f 2 -D 800 -S 3 1.1.2.2

参考资料

返回资源中心

技术手册-Kolla-Ansible：在容器环境中部署OpenStack

关注星融元

OpenStack简介

OpenStack是一个云操作系统，它控制整个数据中心的大型计算、存储和网络资源池，所有这些资源都通过一个仪表板进行管理，该仪表板赋予管理员控制权，同时允许用户通过web界面提供资源。

它为私有云和公有云提供可扩展的弹性的云计算服务，提供实施简单、可大规模扩展、丰富、标准统一的云计算管理平台。

Kolla-Ansible简介

Kolla旨在为运行OpenStack提供生产就绪的容器和部署工具。

Kolla-Ansible是Kolla的子项目，该项目使用Ansible部署Kolla容器映像。

Kolla-Ansible是开箱即用的工具，即使你是个新手也可以快速部署OpenStack，也允许你根据需求定制化的部署。

目标

在容器中部署OpenStack最大的特点就是升级，用户基本是无感知的状态下完成。同时可以实现本地与云端一致，一次开发随处运行，通过迁移到不同的设备，快速的完成部署和升级操作。

本文将以详细操作指导的方式，给出一种在Docker容器环境中部署OpenStack的指导方法。

环境准备

两台server，一台作为controller，另一台作为compute节点，操作系统CentOS 7.6.1810 镜像CentOS-7-x86_64-DVD-1810.iso。服务器具体配置要求如下：

2个千兆网口
至少8G内存
磁盘至少40G
计算节点的BISO中开启CPU嵌套虚拟化(INTEL叫VT-x，AMD的叫AMD-V)

Kolla-Ansible部署过程

关闭SELinux 【控制节点、计算节点】

SELinux不关闭的情况下无法实现，会限制ssh免密码登录

[root@localhost ~]#setenforce 0

[root@localhost ~]# sed -i ‘s/SELINUX=enforcing/SELINUX=disabled/g’ /etc/sysconfig/selinux

关闭防火墙【控制节点、计算节点】

防止安装时出现各个组件的端口不能访问的问题

[root@localhost ~]#systemctl stop firewalld && systemctl disable firewalld

禁用宿主机的 Libvirt 服务

大多数操作系统会默认启动 Libvirt，但使用 Kolla 来部署 OpenStack 的话，Libvirt 应该在容器中运行并管理虚拟机。所以宿主机的 Libvirt 需要被关闭，以免造成冲突。

[root@localhost ~]#systemctl stop libvirtd.service
[root@localhost ~]#systemctl disable libvirtd.service

设置主机名，hosts文件【控制节点、计算节点】

控制节点

[root@localhost ~]#hostname controller
[root@localhost ~]#echo “controller”> /etc/hostname

计算节点根据节点名称修改

[root@localhost ~]#vim /etc/hosts
192.168.4.2 controller
192.168.4.150 computer1

修改网卡名称【控制节点、计算节点】

说明：网卡名字不是必须改，保持各服务器使用的网卡名称一样。

网卡1:

[root@localhost ~]#cd /etc/sysconfig/network-scripts
[root@localhost ~]#vim ifcfg-enp6s0f0
IPADDR=192.168.1.*
NETMASK=255.255.255.0
GATEWAY=192.168.1.1
NAME=eno1
DEVICE=eno1

网卡2:

[root@localhost ~]#cd /etc/sysconfig/network-scripts
[root@localhost ~]#vim ifcfg-enp6s0f1
IPADDR=192.168.2*
NETMASK=255.255.255.0
GATEWAY=192.168.21
NAME=eno2
DEVICE=eno2

修改网卡文件名称:

[root@localhost ~]#mv ifcfg-enp6s0f0 ifcfg-eno1
[root@localhost ~]#mv ifcfg-enp6s0f1 ifcfg-eno2

修改net配置文件

[root@localhost ~]#vi /etc/udev/rules.d/70-persistent-net.rules
SUBSYSTEM==”net”,ACTION==”add”,DRIVERS==”?*”,ATTR{address}==”78:24:af:85:0c:ac”,ATTR{type}==”1″, NAME=”eno1″
SUBSYSTEM==”net”,ACTION==”add”,DRIVERS==”?*”,ATTR{address}==”78:24:af:85:0c:ad”,ATTR{type}==”1″, NAME=”eno2″

ATTR和服务器两网口MAC地址保持一致

重启服务器

[root@localhost ~]#reboot

重启网络服务

[root@localhost ~]#systemctl restart network

安装【控制节点、计算节点】

[root@localhost ~]#yum install -y epel-release
[root@localhost ~]#yum install -y python-pip
[root@localhost ~]#pip install -U pip

安装编译环境【控制节点】

[root@controller ~]#yum install -y python-devel libffi-devel gcc openssl-devel libselinux-python

安装ansible【控制节点】

[root@controller ~]#pip install -U ansible

l 安装docker【控制节点、计算节点】

[root@localhost ~]#tee /etc/yum.repos.d/docker.repo <<-‘EOF’
[dockerrepo]
name=Docker Repository
baseurl=https://yum.dockerproject.org/repo/main/centos/7/
enabled=1
gpgcheck=1
gpgkey=https://yum.dockerproject.org/gpg
EOF
[root@localhost ~]#yum install -y docker-engine docker-engine-selinux

问题1 安装docker失败，提示与其他安装包冲突Error: docker-engine-selinux conflicts with 2:container-selinux-2.107-3.el7.noarch

解决方法如下：

[root@compute1 ~]#rpm -qa |grep container-selinux-2.107-3.el7.noarch
[root@compute1 ~]#yum -y remove container-selinux-2.107-3.el7.noarch

设置Docker【控制节点、计算节点】

[root@localhost ~]#mkdir /etc/systemd/system/docker.service.d
[root@localhost ~]#tee /etc/systemd/system/docker.service.d/kolla.conf << ‘EOF’
[Service]
MountFlags=shared
EOF

重启相关服务【控制节点、计算节点】

[root@localhost ~]#systemctl daemon-reload
[root@localhost ~]#systemctl enable docker
[root@localhost ~]#systemctl restart docker

安装模块【控制节点、计算节点】

[root@localhost ~]#pip install docker

安装【控制节点】

[root@controller ~]#yum install git

安装kolla-ansible【控制节点】

[root@controller ~]#pip install kolla-ansible

如果报如下错误

Cannot uninstall ‘PyYAML’. It is a distutils installed project and thus we

cannot accurately determine which files belong to it which would lead to only a

partial uninstall.

[root@controller ~]#rm -rf /usr/lib64/python2.7/site-packages/PyYAML*

拷贝配置文件【控制节点】

[root@controller ~]#cp -r /usr/share/kolla-ansible/etc_examples/kolla /etc/kolla/

[root@controller ~]#cp /usr/share/kolla-ansible/ansible/inventory/* /home/

配置免密登录【控制节点】

[root@controller ~]#ssh-keygen                        #一路回车
[root@controller ~]#ssh-copy-id controller         #回车后输入服务器密码
[root@controller ~]#ssh-copy-id computer1          #回车后输入服务器密码

存储节点配置【计算节点】

(演示版本可以跳过此步骤)

要启动cinder存储服务，需先添加一块新的硬盘，然后创建pv、vg

[root@computer1 ~]#pvcreate /dev/sdb
[root@computer1 ~]#vgcreate cinder-volumes /dev/sdb //vg名取名为 cinder-volumes，这里主要跟 kolla配置文件里vg名一致

问题1 如果出现创建不了pv

解决方法如下：

[root@compute1 ~]#pvcreate devsdb
Device /dev/sdb excluded by a filter.

解决：

[root@compute1 ~]#dd if=/dev/urandom of=/dev/sdb bs=512 count=64
64+0 records in
64+0 records out
32768 bytes (33 kB) copied, 0.00760562 s, 4.3 MB/s
[root@compute1 ~]#pvcreate /dev/sdb
Physical volume “/dev/sdb” successfully created.

重启服务【计算节点】

[root@compute1 ~]#systemctl restart lvm2-lvmetad.service

修改【控制节点】

[root@controller ~]#vim /home/multinode
[control]
controller
[network]
controller
[inner-compute]
[external-compute]
computer1
[compute:children]
inner-compute
external-compute
[storage]
computer1
[monitoring]
controller
[deployment]
controller

获取docker镜像【控制节点、计算节点】

使用kolla官方镜像源

[root@localhost ~]#vim /etc/kolla/globals.yml
kolla_install_type: “binary”
openstack_release: “stein”
docker_namespace: “kolla”

下载镜像包

[root@controller ~]#kolla-ansible pull -i /home/multinode

修改全局配置文件globals.yml【控制节点】

管理网口eno1,外网网口eno2

如果采用cinder磁盘存储

kolla_base_distro: “centos”

kolla_install_type: “binary”
openstack_release: “stein”
kolla_internal_vip_address: “192.168.4.2”
# Valid options are [ qemu, kvm, vmware, xenapi ]
nova_compute_virt_type: “kvm”
network_interface: “eno1”
api_interface: “{{ network_interface }}”
neutron_external_interface: “eno2”
neutron_plugin_agent: “openvswitch”
enable_cinder: “yes”
enable_cinder_backend_iscsi: “no”
enable_cinder_backend_lvm: “yes”
enable_haproxy: “yes”
enable_heat: “yes”
glance_enable_rolling_upgrade: “no”
ironic_dnsmasq_dhcp_range:
tempest_image_id:
tempest_flavor_ref_id:
tempest_public_network_id:
tempest_floating_network_name:

如果采用外部ceph存储：

kolla_base_distro: “centos”


kolla_install_type: “binary”
openstack_release: “stein”
kolla_internal_vip_address: “192.168.4.2”
# Valid options are [ qemu, kvm, vmware, xenapi ]
nova_compute_virt_type: “qemu”
nova_backend_ceph: “yes”
network_interface: “eno1”
api_interface: “{{ network_interface }}”
neutron_external_interface: “eno2”
neutron_plugin_agent: “openvswitch”
enable_ceph: “no”
enable_cinder_backup: “yes”
cinder_backup_driver: “ceph”
enable_cinder: “yes”
enable_cinder_backend_iscsi: “no”
enable_cinder_backend_lvm: “no”
enable_haproxy: “yes”
enable_heat: “yes”
enable_sahara: “yes”
enable_trove: “yes”
cinder_backend_ceph: “yes”
glance_backend_ceph: “yes”
glance_enable_rolling_upgrade: “no”
ironic_dnsmasq_dhcp_range:
tempest_image_id:
tempest_flavor_ref_id:
tempest_public_network_id:
tempest_floating_network_name:

生成密码文件passwords.yml【控制节点】

这个密码文件可以使用工具自动生成，也可以手动输入但是手动输入需要注意格式，在：后需要空一格

再输入；而且ssh_key也比较麻烦所以推荐使用工具自动生成但是直接输入

[root@controller ~]#kolla-genpwd

修改dashboard登录密码

[root@controller ~]#vi /etc/kolla/passwords.yml

keystone_admin_password: admin

修改部署文件multinode【控制节点】

[root@controller ~]#vim /home/multinode
[control]
controller
[network]
controller
[inner-compute]
[external-compute]
computer1
[compute:children]
inner-compute
external-compute
[monitoring]
controller
[storage]
computer1
[deployment]
localhost ansible_connection=local

检查配置【控制节点】

[root@controller ~]#kolla-ansible prechecks -i /home/multinode

配置SchedNova主机基础环境【控制节点】

[root@controller ~]#kolla-ansible -i /home/multinode bootstrap-servers

部署OpenStack【控制节点】

[root@controller ~]#kolla-ansible deploy -i /home/multinode

验证OpenStack安装【控制节点】

[root@controller ~]#kolla-ansible post-deploy -i /home/multinode

OpenStack更新【控制节点】

### 修改镜像版本（此处不用更新,以后想更新版本再更新）

[root@controller ~]# vim /etc/kolla/globals.yml
openstack_release: “stein”
[root@controller ~]# kolla-ansible upgrade -i /home/multinode

重启所有应用【控制节点】

[root@controller ~]#kolla-ansible -i /home/multinode reconfigure

环境还原【控制节点】

#如果安装有错误，想重新安装，可以选择如下操作

##将删除所有容器和卷

[root@controller ~]#kolla-ansible destroy –yes-i-really-really-mean-it -i /home/multinode

生成 admin-openrc.sh【控制节点】

[root@controller ~]#kolla-ansible post-deploy

初始demo【控制节点】

执行后会自动下载cirros镜像, 创建网络, 并创建一批测试虚拟机.

[root@controller ~]#/usr/share/kolla-ansible/init-runonce

查询登录密码【控制节点】

[root@controller ~]#grep admin /etc/kolla/passwords.yml

安装OpenStack命令行客户端【控制节点】

[root@controller ~]#pip install python-openstackclient

创建实例到指定计算节点

查看有效区域

[root@controller ~]#openstack availability zone list

查看有效主机列表

[root@controller ~]#openstack host list

查看有效计算节点列表

[root@controller ~]#openstack hypervisor list

查询网络id

[root@controller ~]#openstack network list

查看安全组

[root@controller ~]#openstack security group list

创建flavor

[root@controller ~]#openstack flavor create –id 0 –vcpus 1 –ram 64 –disk 1 m1.nano
[root@controller ~]#openstack flavor create –id 1 –vcpus 1 –ram 512 –disk 1 m1.tiny
[root@controller ~]#openstack flavor create –id 2 –vcpus 1 –ram 2048 –disk 20 m1.small
[root@controller ~]#openstack flavor create –id 3 –vcpus 2 –ram 4096 –disk 40 m1.medium
[root@controller ~]#openstack flavor create –id 4 –vcpus 4 –ram 8192 –disk 80 m1.large
[root@controller ~]#openstack flavor create –id 5 –vcpus 8 –ram 16384 –disk 160 m1.xlarg

创建实例

[root@controller ~]#openstack server create –flavor m1.nano \
–image cirros \
–nic net-id=88b84388-40d2-48d9-b4ec-ab0dfa9b244e \
–security-group 5431def1-8856-4e48-ab02-50b9d459f9b1 \
–key-name mykey \
–availability-zone nova:computer2:computer2 instance2

–flavor 实例类型

–image 镜像

–nic 网络 net-id网络id 第4步查得

–availability-zone nova:compute1:compute1 前三步查得

compute1为指定计算节点。

结论

从上面的安装过程我们发现Kolla-Ansible来完成OpenStack安装过程非常的简洁，不需要过多修改OpenStack的配置文件，从而可以很轻松的完成部署和升级等操作。

参考资料

OpenStack官网： openstack.org
Kolla-Ansible项目官网：https://wiki.openstack.org/wiki/Kolla#Kolla
Kolla-Ansible官网安装：https://docs.openstack.org/kolla-ansible/latest/

技术手册-虚拟扩展本地局域网协议VXLAN

关注星融元

VXLAN全称Virtual eXtensible Local Area Network即虚拟扩展局域网，是由IETF定义的NVO3（Network Virtualization over Layer 3）标准技术之一，是对传统VLAN协议的一种扩展。VXLAN的特点是将L2的以太帧封装到UDP报文（即L2 over L4）中，并在L3网络中传输。

VXLAN的产生背景

数据中心规模的壮大，虚拟机数量的快速增长与虚拟机迁移业务的日趋频繁，给传统的“二层+三层”数据中心网络带来了新的挑战：

虚拟机规模受网络设备表项规格的限制

对于同网段主机的通信而言，报文通过查询MAC表进行二层转发。服务器虚拟化后，数据中心中VM的数量比原有的物理机发生了数量级的增长，伴随而来的便是虚拟机网卡MAC地址数量的空前增加。一般而言，接入侧二层设备的规格较小，MAC地址表项规模已经无法满足快速增长的VM数量。

传统网络的隔离能力有限

VLAN作为当前主流的网络隔离技术，在标准定义中只有12比特，也就是说可用的VLAN数量只有4096。对于公有云或其它大型虚拟化云计算服务这种动辄上万甚至更多租户的场景而言，VLAN的隔离能力显然已经力不从心。

虚拟机迁移范围受限

虚拟机迁移，顾名思义，就是将虚拟机从一个物理机迁移到另一个物理机，但是要求在迁移过程中业务不能中断。要做到这一点，需要保证虚拟机迁移前后，其IP地址、MAC地址等参数维持不变。这就决定了，虚拟机迁移必须发生在一个二层域中。而传统数据中心网络的二层域，将虚拟机迁移限制在了一个较小的局部范围内。值得一提的是，通过堆叠、SVF、TRILL等技术构建物理上的大二层网络，可以将虚拟机迁移的范围扩大。但是，构建物理上的大二层，难免需要对原来的网络做大的改动，并且物理大二层网络的范围依然会受到种种条件的限制。

VXLAN采用L2 over L4（MAC-in-UDP）的报文封装模式，将二层报文用三层协议进行封装，可实现二层网络在三层范围内进行扩展，同时满足数据中心大二层虚拟迁移和多租户的需求。

VXLAN的发展历程

协议最早由VMware、Arisa网络、Cisco提出，后期加入华为、博科、Red Hat、Intel等公司支持，IETF于2012年8月发布第一个RFC Internet Draft版本，最新的标准是2014年8月RFC 7348。

VXLAN的相关概念

NVO3（Network Virtualization Over Layer3 3层之上的网络虚拟化）

基于IP Overlay的虚拟局域网络技术统称为NVO3。

NVE(Network Virtrualization Edge网络虚拟边缘节点）

是实现网络虚拟化的功能实体，VM里的报文经过NVE封装后，NVE之间就可以在基于L3的网络基础上建立起L2虚拟网络。网络设备实体以及服务器实体上的VSwitch都可以作为NVE。

VTEP（VXLAN Tunnel Endpoints，VXLAN隧道端点）

VXLAN网络的边缘设备，是VXLAN隧道的起点和终点，VXLAN报文的相关处理均在这上面进行。VTEP既可以是一个独立的网络设备，也可以是虚拟机所在的服务器。

VNI（VXLAN Network Identifier，VXLAN 网络标识符）

VNI类似VLAN ID，用于区分VXLAN段，不同VXLAN段的虚拟机不能直接二层相互通信。一个VNI表示一个租户，即使多个终端用户属于同一个VNI，也表示一个租户。VNI由24比特组成，支持多达16M（(2^24-1)/1024^2）的租户。

VXLAN隧道

“隧道”是一个逻辑上的概念，它并不新鲜，比如大家熟悉的GRE。说白了就是将原始报文“变身”下，加以“包装”，好让它可以在承载网络（比如IP网络）上传输。从主机的角度看，就好像原始报文的起点和终点之间，有一条直通的链路一样。而这个看起来直通的链路，就是“隧道”。顾名思义，“VXLAN隧道”便是用来传输经过VXLAN封装的报文的，它是建立在两个VTEP之间的一条虚拟通道。

BD（bridge domain）,vxlan转发二层数据报文的广播域，是承载vxlan数据报文的实体。类似于传统网络中VLAN的概念，只不过在VXLAN网络中，它有另外一个名字BD。不同的VLAN是通过VLAN ID来进行区分的，那不同的BD是通过VNI来区分的。
VXLAN报文格式

VXLAN报文格式

图1： VXLAN报文格式

VXLAN标准报文格式

图2：VXLAN标准报文格式

VXLAN的工作原理

VXLAN网络中的通信过程

结合如下示例简要说明VXLAN网络中的通信过程：

VXLAN通信过程

图3：VXLAN通信过程

图3中 Host-A 和 Host-B 位于 VNI 10 的 VXLAN，通过 VTEP-1 和 VTEP-2 之间建立的 VXLAN 隧道通信。

数据传输过程如下：

Host-A 向 Host-B 发送数据时，Host-B 的 MAC 和 IP 作为数据包的目标 MAC 和 IP，Host-A 的 MAC 作为数据包的源 MAC 和 IP，然后通过 VTEP-1 将数据发送出去。
VTEP-1 从自己维护的映射表中找到 MAC-B 对应的 VTEP-2，然后执行 VXLAN 封装，加上 VXLAN 头，UDP 头，以及外层 IP 和 MAC 头。此时的外层 IP 头，目标地址为 VTEP-2 的 IP，源地址为 VTEP-1 的 IP。同时由于下一跳是 Router-1，所以外层 MAC 头中目标地址为 Router-1 的 MAC。
数据包从 VTEP-1 发送出去后，外部网络的路由器会依据外层 IP 头进行包路由，最后到达与 VTEP-2 连接的路由器 Router-2。
Router-2 将数据包发送给 VTEP-2。VTEP-2 负责解封数据包，依次去掉外层 MAC 头，外层 IP 头，UDP 头和 VXLAN 头。
VTEP-2 依据目标 MAC 地址将数据包发送给 Host-B。

上面的流程我们看到 VTEP 是 VXLAN 的最核心组件，负责数据的封装和解封。

隧道也是建立在 VTEP 之间的，VTEP 负责数据的传送。

VTEP节点工作机制

通过以上通信步骤的描述可以看到，VTEP节点在VXLAN网络通信中起到了至关重要的作用。在VXLAN网络通信中，VTEP节的职责主要有3项：

将虚拟网络通信的数据帧添加VXLAN头部和外部UDP和IP首部。
将封装好的数据包转发给正确的VTEP节点。
收到其他VTEP发来的VXLAN报文时，拆除外部IP、UDP以及VXLAN首部，然后将内部数据包交付给正确的终端。

对于功能2)的实现，即VXLAN数据包的转发过程。当VTEP节点收到一个VXLAN数据包时，需要根据内部以太网帧的目的MAC地址找到与拥有该目的地址的终端直接相连的VTEP地址，因此，这里需要一个目的MAC地址和VTEP节点IP地址的映射关系，VTEP节点利用一个转发表来存储此映射关系。转发表的格式为：<VNI, Inner Dst MAC,VTEP IP>，即给定VNI和目的MAC地址后映射到一个VTEP IP地址。

需要说明的是，映射VTEP节点IP地址时，之所以需要VNI的信息，是因为当存在多租户的情况下，各个租户将会独立组网，此时，多个租户设定的MAC地址有一定的概率会出现重叠，此时我们必须保证每个租户的网络都能独立地正常通信，因此，在为每个租户配置唯一的一个VNI的情况下，给定VNI和目的MAC地址，唯一确定一个VTEP地址。

下图4是一个样例，对于下图中的网络拓扑，分别给出了两个VTEP节点的转发表：

VTEP节点工作过程

图4：VTEP节点工作过程

上图中给出了6个终端，分别属于2个租户，其中，终端T1、T2和T4属于租户1，分配VNI为1，终端T3、T5和T6属于租户2，分配VNI为2，两个VTEP节点的转发表已在图中给出。

每一个VTEP节点都必须拥有完整的转发表才可以正确地进行转发的功能，转发表的学习过程可以基于这样一种简单的策略：通过ARP报文学习，当收到终端发送的数据帧时，首先根据收到数据的端口判定数据发送方的VNI值，根据VNI和数据帧中的目的MAC查找对应的VTEP节点，如果查找成功，则转发，否则，在当前VXLAN网络中广播ARP请求报文，这样，连接目的MAC终端的VTEP节点就会发送ARP回答报文，这样就学习到了新的转发表项。

需要说明的是，在多租户的环境下，基于信息安全等因素，各个租户的流量必须实现隔离，因此在发送广播ARP请求报文时，不可以直接在多租户的环境中广播，必须保证只有当前VXLAN网络的终端可以收到广播报文，因此，和物理网络中的ARP广播请求的实现有所不同，这里需要通过IP组播机制来模拟广播。

因此，VTEP节点还需要保存对应于每个租户的VNI值的组播域，即对于每一个VNI值，存储包含当前VXLAN网络中终端的所有VTEP节点的IP，用于ARP广播时的组播操作。

VXLAN二层网关与三层网关

VXLAN二层网关：用于终端接入VXLAN网络，也可用于同一VXLAN网络的子网通信。
VXLAN三层网关：用于VXLAN网络中跨子网通信以及访问外部网络。

VXLAN集中式网关与分布式网关

根据三层网关部署方式的不同，VXLAN三层网关又可以分为集中式网关和分布式网关。

VXLAN集中式网关

集中式网关是指将三层网关集中部署在一台设备上，如下图所示，所有跨子网的流量都经过这个三层网关转发，实现流量的集中管理。

图5：

部署集中式网关的优点和缺点如下：

优点：对跨子网流量进行集中管理，网关的部署和管理比较简单。
缺点：转发路径不是最优：同一二层网关下跨子网的数据中心三层流量都需要经过集中三层网关绕行转发（如图中橙色虚线所示）。
ARP表项规格瓶颈：由于采用集中三层网关，通过三层网关转发的终端的ARP表项都需要在三层网关上生成，而三层网关上的ARP表项规格有限，这不利于数据中心网络的扩展。
VXLAN分布式网关

VXLAN分布式网关是指在典型的“Spine-Leaf”组网结构下，将Leaf节点作为VXLAN隧道端点VTEP，每个Leaf节点都可作为VXLAN三层网关（同时也是VXLAN二层网关），Spine节点不感知VXLAN隧道，只作为VXLAN报文的转发节点。如下图所示，Server1和Server2不在同一个网段，但是都连接到一个Leaf节点。Server1和Server2通信时，流量只需要在Leaf1节点进行转发，不再需要经过Spine节点。

部署分布式网关时：

Spine节点：关注于高速IP转发，强调的是设备的高速转发能力。
Leaf节点：作为VXLAN网络中的二层网关设备，与物理服务器或VM对接，用于解决终端租户接入VXLAN虚拟网络的问题。作为VXLAN网络中的三层网关设备，进行VXLAN报文封装/解封装，实现跨子网的终端租户通信，以及外部网络的访问。

VXLAN分布式网关

图6：VXLAN分布式网关

VXLAN分布式网关具有如下特点：

同一个Leaf节点既可以做VXLAN二层网关，也可以做VXLAN三层网关，部署灵活。

Leaf节点只需要学习自身连接服务器的ARP表项，而不必像集中三层网关一样，需要学习所有服务器的ARP表项，解决了集中式三层网关带来的ARP表项瓶颈问题，网络规模扩展能力强。

VXLAN在星融元交换机上的配置实例

下面实例中星融元的两台CX306交换机通过配置BGP EVPN来实现VXLAN网络的建立。

CX306交换机通过配置BGP EVPN来实现VXLAN网络的建立

全文请注册/登录后获取：https://asterfusion.com/d-20220617/

技术手册-防火墙IP TABLES

关注星融元

IP Tables相关名词释义

iptables：iptables是一个用户空间工具，系统管理员可以通过它配置Linux内核防火墙的IP数据包的过滤规则，而这些规则的具体实现是由内核空间的netfilter完成的；
netfilter：netfilter是4.x版本Linux内核开始引入的一个子系统，它作为一个通用的、抽象的框架，提供一套完整的hook函数管理机制，实现了诸如数据包过滤、网络地址转换和基于协议类型的连接跟踪等功能；
hook函数：Linux内核中的有一套hook函数机制，可在不同hook点位置监控网络数据包，并执行丢弃、修改等操作，Linux内核的网络防火墙就是通过此机制实现的。

IP Tables的发展历史

目前iptables已在2.4、2.6及3.0版本的Linux内核中集成，旧版的Linux内核则使用ipchains及ipwadm来达成类似的功能，而2014年1月19日起发行的新版Linux内核（3.13+）则使用nftables取代iptables。

Linux内核（2+）：ipwadm；
Linux内核（2）：ipchains；
Linux内核（4、2.6、3.0+）：iptables；
Linux内核（13+）：nftables。

iptables虽然强大但是不可能永远适用于当前的技术发展，任何技术都有其局限性。位于用户空间的iptables，也在被抛弃，RHEL7/CentOS7中已经不再直接使用iptables，而选择firewalld作为他的前端配置工具。

iptables已在Linux内核中集成

IP Tables原理简介

管理工具iptables是与内核网络协议栈中有包过滤功能的5个hook交互来完成工作的，这些内核hook构成netfilter框架。每个进出网络的包在经过协议栈时都会触发这些hook，数据包在内核中的处理路径如下图所示。

数据包在内核中的处理路径

通过iptables下发的规则，最终都会与上图中标注的5个hook点位关联。iptables将这些规则，按照不同的作用划分到不同的表中，按照划分常用的有raw、mangle、filter、nat四张表，即为四表。而关联在5个hook点位的有优先级顺序的规则链，即为五链。这种配置管理逻辑，也就是使用iptables的人都最为熟知的“四表五链”。

下面是iptables常用的四种table类型及其具体作用：

iptables常用的四种table类型

Filter table：是最常用的table之一，用于判断是否允许一个包通过；
Nat table：用于实现数据包的IP地址转换；
Mangle table：用于修改包的IP头；
Raw table：iptables防火墙是有状态的，raw table其唯一目的就是让数据包绕过连接跟踪机制。

表和链的组织逻辑是：不同的表可以作用在不同的链（hook点位）中，在具体链中多种表之间又有优先级顺序，具体如下图所示，红色箭头方向表示各表的优先级顺序依次从高到低排列。

具体链中多种表之间又有优先级顺序

我们通过iptables下发的规则就放置在特定table的特定chain里面，当chain被触发调用的时候，包会依次匹配chain里面的规则，每条规则都有一个匹配部分和一个动作部分。规则的匹配部分指定了一些条件，数据包必须满足这些条件才会和将要执行的动作进行关联。匹配系统非常灵活，还可以通过iptables extension扩展其功能。规则可以匹配协议类型、源目地址、源目端口、源目网段、接收或发送的网卡、协议头、连接状态等条件。这些综合起来，能够组合成非常复杂的规则来区分不同的网络流量。

总结

netfilter包过滤框架和iptables是Linux服务器上大部分防火墙解决方案的基础。其中，netfilter的内核hook与Linux内核协议栈配合得足够紧密，提供了数据包在经过系统时的强大控制能力。而iptables正是基于这些能力提供了一个灵活的、可扩展的、将策略需求转化到内核的方法。理解了这些不同部分是如何联系到一起的，就可以使用iptables创建出可靠的防火墙策略。

IP Tables的应用场景

通过上文可以清楚地了解到，iptables其实是存在于操作系统应用层，作为配置内核中安全框架netfilter的一个客户端。通过iptables可以实现常规防火墙的几乎所有的功能，包括但不限于：

提供基于状态的源目IP地址、源目端口、访问时间等维度的访问控制；
提供双向NAT能力，配合Linux的网络工具可以在网络出口实现链路负载均衡功能；
利用iptables的limit模块，可以实现轻量的DDoS攻击防护；
利用iptables的connlimit模块，可以防护CC攻击；
利用iptables的string模块，对数据包中的内容进行检查，实现报文深度过滤或者数据脱敏功能；
按需管理iptables的日志，可以为不同规则设置不同的日志标识，以便灵活记录数据流日志。

除了作为常规的主机/网络防火墙外，iptables也作为重要的网络组成部分，存在于Docker、K8S、OpenStack的Neutron项目以及众多成熟且应用广泛的开源项目中。

IP Tables的部署实例

首先，简单了解下iptables命令的语法格式，命令格式可分解为如下几部分。

iptables -t <table> <cmd> <pattern> <action>

其中，-t <table>或–table <table>选项用来指定要查看或修改的表（raw、mangle、nat、filter），命令行在不使用-t参数时默认为filter表。<cmd>部分可选择对规则要进行的操作，即增删改查操作，<pattern>为规则的匹配部分，<action>为安全规则的动作部分，对匹配到的数据包做指定的动作。

屏蔽指定IP地址：若发现某个恶意攻击者并确定其IP地址，此时可以使用如下命令将指定IP的数据包丢弃。

BLOCK_THIS_IP=”x.x.x.x”

iptables -A INPUT -i eth0 -p tcp -s “$BLOCK_THIS_IP” -j DROP

此命令行，<cmd>部分使用-A INPUT参数将屏蔽规则插入到filter表（默认）的INPUT链尾。

网卡流量转发：如果在某些场景下使用服务器作为网关，则可能需要两张网卡分别接内网和公网，然后需要将内网的网卡流量转发到连接到公网的网卡中，可以使用iptables实现此功能，命令行如下所示。

iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT

端口流量转发：若需要进行端口级别的流量转发，使用iptables同样可以完成，此命令会将2222端口流量转发到22。

iptables -t nat -A PREROUTING -p tcp -d 192.168.1.5 –dport 2222 -j DNAT –to 192.168.1.5:22

使用扩展模块实现WEB流量简单负载：下面将使用nth扩展模块，将80端口流量负载均衡到三台服务器。

iptables -A PREROUTING -i eth0 -p tcp –dport 80 -m state –state NEW -m statistic –mode nth –every 3 –packet 0 -j DNAT –to-destination 192.168.1.11:80

iptables -A PREROUTING -i eth0 -p tcp –dport 80 -m state –state NEW -m statistic –mode nth –every 2 –packet 0 -j DNAT –to-destination 192.168.1.12:80

iptables -A PREROUTING -i eth0 -p tcp –dport 80 -m state –state NEW -m statistic –mode nth –every 1 –packet 0 -j DNAT –to-destination 192.168.1.13:80

在上面的命令行中，采用statistic模块的nth模式来实现轮询的负载均衡效果，参数含义如下：

–every n表示每n个命中就会真正执行一次；
–packet p表示在这条规则的第几次命中时真正执行（0<=p<=n-1）。

需要注意的是，每条规则有独立的计数器，因此-m statistic –mode nth –every 3 –packet 0表示每三个包触发一次动作，在第0次命中时执行动作，在第1次和第2次命中后不触发动作，而是将数据包交给下一条规则处理。同理，第二个包的匹配规则为-m statistic –mode nth –every 2 –packet 0，第三个包的匹配规则为-m statistic –mode nth –every 1 –packet 0。

使用扩展模块实现DDoS流量清洗：下面将使用limit扩展模块，来实现简单的DDoS攻击流量清洗。

iptables -A INPUT -p tcp –dport 80 -m limit –limit 5/minute –limit-burst 100 -j ACCEPT

关于limit限速模块，各参数的含义如下：

–limit n/s表示s时间段内会新签发n个令牌，时间单位有秒、分、时、天；
–limit-burst m表示初始令牌数量以及令牌桶的最大容量。

IP Tables的配置总结

IP Tables的配置

技术手册-RoCEv2 / EVPN-VXLAN / MC-LAG 部署

关注星融元

本文主要描述如何在Asterfusion CX306P-48S（以下简称CX306P）搭建的模拟网络上部署如下解决方案：

RoCEv2：在模拟网络上承载RDMA应用，通过CX306P的PFC和ECN功能，为所承载的RDMA应用构建无损的RoCEv2环境。

BGP EVPN和VXLAN：在模拟网络上承载VXLAN网络，将原本在Open vSwitch上进行的封装、去封装全部从Server端卸载到CX306P内的VTEP上，并且在模拟网络上启动BGP EVPN，自动化地创建VXLAN隧道、传递虚拟网络路由。

MC-LAG：在模拟网络上为服务器创建一个高可靠环境，确保每台服务器都能通过标准LAG双上联到两台CX306P上，这两台CX306P通过MC-LAG被虚拟化成一台高可靠的交换节点。

如上解决方案共用一个物理拓扑，如图1所示：

CX-N的部署拓扑图

部署过程中所涉及到的设备、接口及管理网口的IP地址如下表所示：

设备名称	接口	IP地址
交换机A	管理口	192.168.4.102
交换机B	管理口	192.168.4.105
Server1	管理口	192.168.4.2
Server2	管理口	192.168.4.133
Server3	管理口	192.168.4.150

RoCEv2 / EVPN-VXLAN / MC-LAG部署的硬件与软件环境

部署环境中涉及到的硬件和软件如下表所示：

名称	型号	硬件指标	数量	备注
交换机	CX306P	《参见产品彩页》	2
服务器		1、至少8G内存 2、磁盘不少于500G 3、Server1和Server3的BIOS开启CPU嵌套虚拟化（INTEL：VT-x, AMD:AMD-V）	3	Server1和Server3各需要安装一块Mellanox ConnectX-4网卡（25G）
光模块	10G	SFP+	12
	100G	QSFP28	4
光纤	多模	10G/25G适用	6
	多模	100G适用	2

软件	版本	备注
操作系统	Centos7.6	安装时选择Compute Node 模式，根目录/至少500G
iperf3		可以直接yum install iperf3安装，3台server均需要安装
Mellanox网卡驱动	4.7-3.2.9.0	具体参考《解决方案-Mellanox网卡驱动安装-e-20200211-v1.1》
tcpdump		可以直接yum install tcpdump

RoCEv2的配置部署

逻辑组网与配置思路

RoCEv2的配置部署逻辑组网与配置思路

配置思路：

为交换机A和交换机B配置IP和路由
分别为Server1、Server2、Server3配置IP和路由网关
配置Server1的PFC功能
配置交换机A的ACL打标DSCP功能
使能交换机A和交换机B的QOS功能
先在Server1发送IB流量，观察队列流量
停掉Server1上的流量发送，在Server2发送普通TCP背景流量，观察队列流量
观察ACL规则匹配情况
将Server1和Server2的流量都打起来，观察交换机B的出口拥塞情况
配置交换机A和交换机B的PFC功能
观察测试PFC功能
关闭交换机A和交换机B的PFC功能，配置交换机B的ECN功能
配置服务器ECN相关设置
测试ECN功能

BGP EVPN和VXLAN配置部署

逻辑组网与配置思路

BGP EVPN和VXLAN配置部署逻辑组网与配置思路

配置思路：

配置交换机A和交换机B的HOSTNAME
配置交换机A的EVPN
配置交换机B的EVPN
Server1上创建虚机和VLAN
Server3上创建虚机和VLAN
测试Server1和Server3的连通性
查看交换机A的路由信息
查看交换机B的路由信息

MC-LAG的配置部署思路

逻辑组网与配置思路

MC-LAG的配置部署思路逻辑组网与配置思路

配置思路：

分别为Server1、Server3配置LAG
交换机A创建PortChannel，并添加接口
交换机A创建VLAN，并添加成员
交换B创建PortChannel，并添加接口
交换机B创建VLAN，并添加成员
交换机A配置MC-LAG
交换机B配置MC-LAG
测试链路故障
测试设备故障

全文请注册/登录后获取：https://asterfusion.com/d-20220617/

测试报告-HPC高性能计算测试方案（CX-N系列云交换机）

关注星融元

一位来自金融行业的客户，他们希望可以实时地模拟和响应风险，以实现企业金融风险管理能力的提升。事实上，不管是金融行业还是其他行业，要想加快步伐满足快速数字化世界中的客户需求，就必须能够比标准计算机更快地处理大量数据。高性能计算（HPC)解决方案，正在受到企业们的青睐。

HPC通用架构主要由计算、存储、网络组成，而HPC之所以能够提高计算速度，更多是采用了“并行技术”，使用多个计算机协同工作，采用十台、百台，甚至成千上万台计算机“并行工作”。各个计算机之间需要互相通信，并对任务进行协同处理，这就需要建立一套对时延、带宽等有着严格要求的高速网络。

高带宽、低时延和低资源使用率的RDMA模式（主要体系架构：InfiniBand协议和以太网协议），往往是HPC网络的最佳选择。而星融元CX-N 超低时延交换机（简称CX-N)采用了标准以太网协议和开放软硬件技术，支持无损以太网技术和网络无损防拥塞技术，充分满足用户HPC应用下对网络带宽、时延等的高要求。为验证这一事实，我们选用Mellanox的InfiniBand交换机，与其进行了相同HPC应用下的运行速度的对比测试。

我们在CX-N和Mellanox的MSB7800交换机（简称IB交换机）分别搭建的网络上，进行了E2E转发测试、MPI基准测试和HPC应用测试。结果证明：CX-N 的时延和对方达到了同一个量级，运行速率较对方仅低3%左右，产品性能与对方交换机不相上下，能够满足绝大多数的HPC应用场景。而有必要补充一点的是，星融元更加注重产品成本的把控，星融元HPC解决方案在性价比方面有显著的优势。

HPC场景测试方案全过程：

1、目标与物理网络拓扑

E2E转发测试
测试两款交换机在相同拓扑下E2E（End to End）的转发时延和带宽，本次方案测试点采用Mellanox IB发包工具进行发包，测试过程遍历2~8388608字节。
MPI基准测试
MPI基准测试常用于评估高性能计算性能。本次方案测试点采用OSU Micro-Benchmarks来评估CX-N和IB两款交换机的性能。
HPC应用测试
本次测试方案在每个HPC应用中运行相同任务，并比较CX-N和IB两款交换机的运行速度（时间更短）。

1.1 IB交换机物理拓扑

如上解决方案的IB交换机物理拓扑，如图1所示：

IB交换机物理网络拓扑

图1：IB交换机物理网络拓扑

1.2 CX-N物理拓扑

如上解决方案的CX-N物理拓扑，如图2所示：

CX-N物理网络拓扑

图2：CX-N物理网络拓扑

1.3 管理网口IP规划

部署过程中所涉及到的设备、接口及管理网口的IP地址如下表1所示：

设备管理口列表

表1：设备管理口列表

2、硬件和软件环境

部署环境中涉及到的硬件和软件如表2和表3所示：

硬件环境

表2：硬件环境

软件环境

表3：软件环境

3、测试环境部署

在两台Server服务器上，安装部署HPC三种测试场景所需的基础环境。

补充说明：以”[root@server ~]#”为开头的命令表示两台服务器都要执行。

3.1 E2E转发测试环境部署

在两台Server服务器上安装Mellanox网卡的MLNX_OFED驱动程序，网卡驱动安装完成之后检查网卡及驱动状态，确保网卡可以正常使用。

网卡MLNX_OFED驱动程序安装：

检查网卡及网卡驱动状态：

3.2 MPI基准测试环境部署

在两台Server服务器上安装HPC高性能集群基础环境，安装OSU MPI Benchmarks MPI通信效率测评工具，测试方式分为点对点通信和组网通信两种方式，通过执行各种不同模式的MPI，来测试带宽和时延。

HPC集群高性能基础环境：

OSU MPI Benchamarks工具安装

3.3 HPC应用测试环境部署

在两台Server服务器上安装HPC测试应用。本次方案部署WRF开源气象模拟软件和LAMMPS原子分子并行模拟器来进行数据测试。

WRF安装部署：

WRF全称Weather Research and Forecasting Model, 是一个天气研究与预报模型的软件。

修改Docker网络配置
本方案两台Server服务器WRF部署采用Docker容器部署，需要修改Docker配置文件，将虚拟网桥绑定到Mellanox网卡上，通过直接路由方式实现跨主机Docker容器通信。

WRF应用部署
LAMMPS安装部署：LAMMPS即Large-scale Atomic/Molecular MassivelyParallel Simulator，大规模原子分子并行模拟器，主要用于分子动力学相关的一些计算和模拟工作。

安装GCC-7.3

安装OpenMPI

安装FFTW

安装LAMMPS

随着云计算技术的成熟，HPC正在从应用于大规模科学计算场景，转变为适用各种科学和商业计算场景。《星融元HPC解决方案》将重磅发布，敬请期待！

全文请注册/登录后获取：https://asterfusion.com/d-20220527/

技术手册-BGP路由协议

关注星融元

BGP全称BorderGatewayProtocol，也叫边界网关协议，是一种路径矢量路由协议，最新版本是BGPv4。BGP是互联网上一个核心的去中心化自治路由协议。BGP是最复杂的路由协议，属于应用层协议，其传输层使用TCP，默认端口号是179。BGP是唯一使用TCP作为传输层的路由协议。

BGP的分类介绍

BGP按照运行方式分为eBGP（External/Exterior BGP）和iBGP（Internal/Interior BGP）。

eBGP：运行于不同AS之间的BGP称为eBGP。为了防止AS间产生环路，当BGP设备接收eBGP对等体发送的路由时，会将带有本地AS号的路由丢弃。
iBGP：运行于同一AS内部的BGP称为iBGP。为了防止AS内产生环路，BGP设备不将从iBGP对等体学到的路由通告给其他iBGP对等体，并与所有iBGP对等体建立全连接。为了解决iBGP对等体的连接数量太多的问题，BGP设计了路由反射器和BGP联盟。

应该注意的是，使用内部 BGP 不是使用外部 BGP 的前提条件。自治系统可以从多种内部协议中进行选择，以连接其内部网络上的路由器。

BGP的相关概念

AS(Autonomous sydstem)

自治系统，指在一个（有时是多个）组织管辖下的所有IP网络和路由器的全体，它们对互联网执行共同的路由策略。一个AS是一个独立的整体网络。每个AS有自己唯一的编号。通常一个自治系统将会分配一个全局的唯一的16位号码， ASN范围：1-65535；其中1-64511属于公有ASN，64512-65535属于私有ASN。

AS_Path

路由每通过一个AS范围都会产生一个记录。

BGP报文交互中的角色

BGP报文交互中分为Speaker和Peer两种角色。

Speaker：发送BGP报文的设备称为BGP发言者（Speaker），它接收或产生新的报文信息，并发布（Advertise）给其它BGP Speadker。
Peer：相互交换报文的Speaker之间互称对等体（Peer）。若干相关的对等体可以构成对等体组（Peer Group）。

BGP的路由器号（Router ID）

BGP的Router ID是一个用于标识BGP设备的32位值，通常是IPv4地址的形式，在BGP会话建立时发送的Open报文中携带。对等体之间建立BGP会话时，每个BGP设备都必须有唯一的Router ID，否则对等体之间不能建立BGP连接。
BGP的Router ID在BGP网络中必须是唯一的，可以采用手工配置，也可以让设备自动选取。缺省情况下，BGP选择设备上的Loopback接口的IPv4地址作为BGP的Router ID。如果设备上没有配置Loopback接口，系统会选择接口中最大的IPv4地址作为BGP的Router ID。一旦选出Router ID，除非发生接口地址删除等事件，否则即使配置了更大的地址，也保持原来的Router ID。

BGP的报文

BGP对等体间通过以下5种报文进行交互，其中Keepalive报文为周期性发送，其余报文为触发式发送：
Open报文：用于协商BGP参数，包括版本，AS号，hold time等，然后建立BGP对等体连接。
Update报文：用于在对等体之间交换路由信息。
Notification报文：用于中断BGP连接。
Keepalive报文：用于保持BGP连接。
Route-refresh报文：用于在改变路由策略后请求对等体重新发送路由信息。只有支持路由刷新（Route-refresh）能力的BGP设备会发送和响应此报文。

BGP的3张表

邻居表(adjancy table):保存所有的BGP邻居信息。
BGP表(forwarding database):保存从每一个邻居学到的路由信息。
路由表(routing table):BGP默认不做负载均衡，会从BGP表中选出一条到达各个目标网络最优的路由，放入路由表保存。路由器只需按路由表保存的路由条目转发数据即可。

全文请注册登录后获取：https://asterfusion.com/d-20230427/

资料下载

一文梳理基于优先级的流量控制（PFC）

什么是PFC（基于优先级的流量控制）

丢包对不同协议的影响有所不同，应用会以不同的方式作出响应：一些应用可以容忍这一情况，通过重新发送所丢数据包得以恢复。以太网能够支持这些情况，但有些应用不能容忍任何丢包情况，要求保证端到端传输没有丢包。为了使以太网能够满足应用的无丢包要求，需要制定一种方法来通过以太网提供无损服务。基于优先级的流量控制PFC就产生了。PFC（Priority-based Flow Control，基于优先级的流量控制）功能是一种精细的流量控制机制，在IEEE 802.1Qbb标准文档中的定义是：对传统流控暂停机制的一种增强。PFC是基于优先级为不同的业务来提供不同服务的，可以解决传统以太网流控机制和该需求之间的冲突。

PFC工作原理

PFC是暂停机制的一种增强，PFC允许在一条以太网链路上创建8个虚拟通道，为每条虚拟通道指定一个优先等级并分配专用的资源（如缓存区、队列等等），允许单独暂停和重启其中任意一条虚拟通道而不影响其他虚拟通道流量的传输，保证其它虚拟通道的流量无中断通过。这一方法使网络能够为单个虚拟链路创建无丢包类别的服务，使其能够与同一接口上的其它流量类型共存。

数据中心场景中发生网络拥塞的原因

产生拥塞的原因有很多，在数据中心场景里比较关键也是比较常见的原因有三点：

进行数据中心网络架构设计时，如果采取非对称带宽设计，即上下行链路带宽不一致。也就是说当下联服务器上行发包总速率超过上行链路总带宽时，就会在上行口出现拥塞。
当前数据中心网络多采用Fabric架构，采用ECMP来构建多条等价负载的链路，并HASH选择一条链路来转发，是简单的。但这个过程没有考虑到所选链路本身是否已经拥塞，对于已经产生拥塞的链路来说，会加剧链路的拥塞。
TCP Incast是Many-to-One（多对一）的通信模式，在数据中心云化的大趋势下这种通信模式常常发生，尤其是那些分布式存储和计算应用，包括Hadoop、MapReduce、HDFS等。如图1所示，当一个Parent Server向一组节点发起请求时，集群中的节点会同时收到请求，并且几乎同时相应。所有节点同时向Parent Server发送TCP数据流，使得交换机上连Parent Server的出端口缓存不足，造成拥塞。

TCP Incast多对一通信模式

图1：TCP Incast多对一通信模式

为了实现端到端的无损转发，避免因为交换机中的Buffer缓冲区溢出而引发的数据包丢失，交换机必须引入其他机制，如流量控制，通过对链路上流量的控制，减少对交换机Buffer的压力，来规避丢包的产生。

PFC流量控制的工作机制

一旦出现瞬时拥塞，即某个设备的队列缓存消耗较快，超过一定的阈值，设备即向数据进入的方向发送反压信息，上游设备收到反压信息，会根据反压信息指示停止发送或延迟发送数据，并将数据存储在本地端口buffer，如果本地端口buffer消耗超过阈值，则继续向上反压。直到网络终端设备，从而消除网络节点因拥塞造成的丢包。

如图2所示，交换机Switch-1和Switch-2的连接端口分别创建8个优先级队列，并为每个队列分配相应的buffer，业务报文通过数据流中携带的优先级字段进行标识，buffer大小使得各队列有不同的数据缓存能力。

PFC工作机制

图2：PFC工作机制

Switch-2的第5优先级队列出现拥塞时，本端报文处理方式：

如果Switch-2使能了PFC功能，向上游设备Switch-1发送PFC Pause帧，通知对端设备暂时停止发送第5优先级队列的报文。对端设备在接收到PFC Pause帧后，将暂时停止向本端发送该类报文，暂停时间长短信息由PFC Pause帧所携带。当拥塞仍然存在时，此过程将重复进行，直至拥塞解除；
如果Switch-2没有使能PFC功能，则直接将报文丢弃。

当Switch-1收到PFC Pause帧时，其报文处理方式是：

若Switch-1使能了PFC功能，且尚未暂停发送第5优先级的报文，则暂停发送该优先级的报文，并根据PFC Pause帧中对应的暂停时间启动定时器。当定时器到期后，将恢复相应优先级报文的发送；
若Switch-1使能了PFC功能，且已经暂停发送第5优先级的报文，则根据PFC Pause帧中对应的暂停时间更新对应定时器的到期时间；
若PFC Pause帧中对应的暂停时间为0，则相当于使对应的暂停定时器立即到期，立即恢复相应优先级报文的发送；
若PFC Pause帧中对应的暂停时间不为0，则相当于复位对应的暂停定时器。也就是说，只要本端一直拥塞，则对端会因不断收到PFC Pause帧而持续暂停发送相应优先级的报文；
若Switch-1没有开启相应优先级的PFC功能，则不会暂停发送相应优先级的报文。

PFC的帧格式

Pause帧实际上是一个以太帧，IEEE802.1Qbb中定义了PFC帧的格式，如图3所示：

PFC帧格式

图3：PFC帧格式

Destination MAC Address：目的MAC地址，为01-80-C2-00-00-01；
Source Mac Address：源MAC地址，为本设备MAC地址；
Ethernet type：以太网帧长度或类型域，为88-08，用于标明本帧的类型为MAC控制帧；
Control opcode：MAC控制操作码，PFC Pause帧仅是MAC控制帧的一种，其在MAC控制帧中的操作码为01-01；
Priority enable vector：优先级使能向量，高字节置0，低字节的每个位代表相应的Time[n]是否有效。E[n]代表优先级n，当E[n]为1时，表示Time[n]有效，处理该优先级的数据流，即停止流量发送；当E[n]为0，表示Time[n]无效，忽略该优先级的数据流，即流量不受影响继续发送；
Time：时间，包含Time[0]至time[7]的8个数组单元，每个数组单元为2字节。当E[n]为0时，Time[n]没有意义。当E[n]为1时，Time[n]代表接收站点抑制优先级为n的报文发送的时间，时间的单位为物理层芯片发送512位数据所需要的时间；
Pad（transmit as zero）：预留，传输时为0；
CRC：循环冗余校验。
PFC死锁

PFC死锁，是指当多个交换机之间因微环路等原因同时出现拥塞,各自端口缓存消耗超过阈值，而又相互等待对方释放资源，从而导致所有交换机上的数据流都永久阻塞的一种网络状态。

正常情况下，当一台交换机的端口出现拥塞时，数据进入的方向(即下游设备)将发送PAUSE帧反压，上游设备接收到Pause帧后停止发送数据，如果其本地端口缓存消耗超过阈值，则继续向上游反压。如此一级级反压，直到网络终端服务器在Pause帧中指定Pause Time内暂停发送数据，从而消除网络节点因拥塞造成的丢包。

但在特殊情况下，例如发生链路故障或设备故障时，如图4所示，当4台交换机都同时向对端发送Pause帧，这个时候该拓扑中所有交换机都处于停流状态，由于PFC的反压效应，整个网络或部分网络的吞吐量将变为零。

PFC死锁

图4：PFC死锁

技术优点

基于优先级的流量控制通常在数据中心的环境中用，与其他的数据中心技术相结合，使设备可支持对丢包极为敏感的高层协议，以满足这些协议冲突时不丢包的要求，而不会影响到使用其他优先级的传统局域网协议。
和普通的流量控制技术相比，基于优先级的流量控制更加灵活。普通的流量控制技术会阻止一条链路上的所有流量，从本质上来讲，它会暂停整条链路。而基于优先级的流量控制技术可对端口上部分优先级的报文启用流量控制，而对其他优先级的报文不启用流量控制，也就是说，可以仅阻止一条链路上的部分流量，而其他的流量正常通过。和普通的流量控制技术一样，基于优先级的流量控制技术也仅适用于点对点全双工链路。

应用场景

PFC 是构建无损以太网的必选手段之一，能够逐跳提供基于优先级的流量控制。通过使用 PFC 功能，使得某种类型的流量拥塞不会影响其他类型流量的正常转发，从而达到同一链路上不同类型的报文互不影响。
PFC 多用于大型在线数据密集服务，如用于在线购物，社交媒体和网络搜索的自动推荐系统，高性能深度学习网络，NVMe 高速存储业务等应用场景。

参考资料

返回资源中心

云化园区

网络操作系统（SONiC）

可视交换机

开放硬件平台

近期文章

名词解释

背景

工作原理

IP层对ECN的支持

IP层ECN报文交互

CNP报文格式

TCP层对ECN的支持

TCP层ECN报文交互

两个ECT Codepoints机制

Fast ECN

配置实例

网络拓扑

服务器端配置

交换机端配置

配置CISCO-LIKE命令行

交换机A

发送流量包

发送流量包

交机限速

观察拥塞情况

交换机A

Server1

配置交换机ECN功能

交换机A

Server1

Server2

观察ECN功能

清空流量包计数

发送IB流量

交换机A

Server1

参考资料

最新动态

关注星融元

OpenStack简介

Kolla-Ansible简介

目标

环境准备

Kolla-Ansible部署过程

关闭SELinux 【控制节点、计算节点】

关闭防火墙【控制节点、计算节点】

禁用宿主机的 Libvirt 服务

设置主机名，hosts文件【控制节点、计算节点】

修改网卡名称【控制节点、计算节点】

安装【控制节点、计算节点】

安装编译环境【控制节点】

安装ansible【控制节点】

l 安装docker【控制节点、计算节点】

设置Docker【控制节点、计算节点】

重启相关服务【控制节点、计算节点】

安装模块【控制节点、计算节点】

安装【控制节点】

安装kolla-ansible【控制节点】

拷贝配置文件【控制节点】

配置免密登录【控制节点】

存储节点配置【计算节点】

重启服务【计算节点】

修改【控制节点】

获取docker镜像【控制节点、计算节点】

修改全局配置文件globals.yml【控制节点】

生成密码文件passwords.yml【控制节点】

修改部署文件multinode【控制节点】

检查配置【控制节点】

配置SchedNova主机基础环境【控制节点】

部署OpenStack【控制节点】

验证OpenStack安装【控制节点】

OpenStack更新【控制节点】

重启所有应用【控制节点】

环境还原【控制节点】

生成 admin-openrc.sh【控制节点】

初始demo【控制节点】

查询登录密码【控制节点】

安装OpenStack命令行客户端【控制节点】

创建实例到指定计算节点

结论

2、硬件和软件环境