在网络虚拟化中，为了最大化资源利用，通常需要将功能和基础设施调度到多个 NUMA 上。在这种情况下该如何配置 OVS DPDK 以保证性能最优，则需要一些额外的分析和配置

使用 OVS DPDK 前用户需要手动为其分配大页内存，但是分配多少大页内存合适呢？这没有一个简单通用的解答，OVS DPDK 需要的大页内存数依赖于许多东西，例如 ports MTU 的大小，ports 所在的 NUMA node。要准确回答这个问题，就要搞清楚 OVS DPDK 是如何使用这些内存的。

IPsec 全称 IP Security，顾名思义它是一个用于保证通信安全的协议，并且多半是在 IP frame 上做的手脚。下面我们来了解一下它。

什么是 IPsec

IPsec 不是一个单独的协议，它是一个协议组。它的目的是为网络层安全提供一个稳定，持久的基础，可用于设备之间的加密连接。它可以保证数据在公网上传输的安全，并且常用于 VPN。它的工作原理是加密 IP 数据包，同时验证数据包的来源。IPsec 通常使用 500 端口。

并非所有 VPN 都是通过 IPsec 实现的，有些 VPN 使用的是 SSL/TLS 协议，它们之间的区别在于它们作用在不同的协议层上。SSL/TLS 作用在传输层。

在看一些开源项目的时候，经常会遇到一些奇怪的 magic numbers，比如 0xdeedbeef，它们经常出现，但是有什么含义呢？

wiki 上对 Hexspeak 的解释如下：

Hexspeak, like leetspeak, is a novelty form of variant English spelling using the hexadecimal digits. Created by programmers as memorable magic numbers, hexspeak words can serve as a clear and unique identifier with which to mark memory or data.

简而言之，hexspeak，就是一种程序员发明的，用 16 进制数来表达的一种变体的英文拼写。

kickstart %pre %post 阶段

在 kickstart 中我们可以通过%pre 和%post 标签添加 pre-installation 脚本和 post-installation 脚本，顾名思义，这两个脚本分别作用在：

• %pre，在系统安装开始之前，kickstart 文件解析之后立即运行；
• %post，在系统完成安装之后运行；

并且%post 默认在 chroot 环境下运行，而%pre 不在 chroot 下运行，这一点在后文调试中会解释。

调试 iso 安装过程

调试 iso 安装过程，首先选 iso 启动，进到安装界面，你可以选 text mode（不带 UI 的字符安装界面）或者带 UI 的界面。

按下Alt+F2切换到 shell。

进入了可以看到以 anaconda 开头的 shell 环境，现在看到的这个就是安装系统用的系统，这个系统非常简洁，只支持很少的与系统安装相关的一些命令，可以通过help命令查看。

安装系统到硬盘的操作就是在这个环境下执行。首先会执行%pre，之后将你选择的硬盘（如/dev/vda）挂载到/mnt/sysimage目录下，并且将系统和 rpm 包安装到该目录下：

这个时候切换到 shell 环境可以看到安装硬盘已经被分区并挂载到/mnt/sysimage目录下了。

再切回 main，等待 rpm 安装完成，

可以看到在 generating initramfs 之后才真正执行%post

而执行%post，是在 chroot 环境下，等同于：

1
2
3

# 在shell tab下
[anaconda root@localhost /]# cd /mnt/sysimage
[anaconda root@localhost sysimage]# chroot .

*重新生成 initramfs

要重新生成 initramfs，只需要执行以下几条指令：

1
2
3

$ KERNEL_VERSION=$(rpm -q kernel --qf '%{version}-%{release}.%{arch}\n')
$ cp /boot/initramfs-${KERNEL_VERSION}.img /boot/initramfs-${KERNEL_VERSION}.bak.$(date +%m-%d-%H%M%S).img
$ /sbin/dracut -f /boot/initramfs-${KERNEL_VERSION}.img ${KERNEL_VERSION}

我们可以在 ks.cfg 中这么写：

%post --log=/var/log/ks_post.log
    KERNEL_VERSION=$(rpm -q kernel --qf '%{version}-%{release}.%{arch}\n')
    cp /boot/initramfs-${KERNEL_VERSION}.img /boot/initramfs-${KERNEL_VERSION}.bak.$(date +%m-%d-%H%M%S).img
    /sbin/dracut -f /boot/initramfs-${KERNEL_VERSION}.img ${KERNEL_VERSION}
%end

Reference

CentOS install guide: https://docs.centos.org/en-US/centos/install-guide/Kickstart2/

Red Hat How to: https://access.redhat.com/solutions/5498341

在我们对 haproxy1.6.9 进行性能测试的时候，为了提升性能，测试出 haproxy 的极限，我们启用了 haproxy不建议使用的多进程 (nbproc)。结果遇到了一些比较麻烦的问题，由于 haproxy 上的统计信息都是存放在 stats 上，但是 stats 只能绑定到一个进程上，这就意味着我们无法统计所有负载均衡进程上的信息。

为了解决这个问题，我们尝试过将多个进程的数据流合并到一个用于统计的进程上，但是这种方式无法解决 haproxy 性能问题（因为最终所有的流都要流向同一个进程）。最后决定通过增大进程可用 fd 数和开启多线程 (nbthread)。

1、Basic Git Workflow

基本的 git 工作流只有一个分支——master 分支。开发者直接提交到 master 分支上，并且使用 master 分支来部署生产环境。

通常我们不建议使用这种工作流，除非你想快速开始一个项目，或者这是一个业余项目。

因为这里只有一个分支，因此实际上是没什么流程的。这使得 git 的使用毫不费力。但是，在使用这种工作流方式时，你需要注意一些点：

1. 协作开发代码时很容易导致冲突；
2. 很容易将有 bug 的版本部署到生成环境；
3. 很难维护干净的代码；

本文将对 SCSI 命令的基本结构进行简单的讲解，详细介绍 SCSI persistent reservations 机制的原理，并演示如何使用sg_persist命令查看 reservation 状态。

virtio-forwarder（VIO4WD）是一个用户空间网络应用，它可以在 SR-IOV virtual functions（VFs）和 QEMU 的 virtio 网络设备之间转发流量。virtio-forwarder 通过 DPDK 轮询模式驱动程序 (PMD) 机制，使用 DPDK 的 vhost-user 库和指定的 VFs 实现 virtio 后端驱动程序。

这意味着，virtio-forward 既采用了 DPDK 和 VFs 来保证网络性能，又通过添加中间层的方式解耦了和 QEMU 虚拟机网卡的绑定，提供了更高的灵活性。

virtio-forwarder 使用 libdpdk 开发，因此 VIO4WD 是一个运行在用户空间的应用，同样的 QEMU 端只能够使用 vhost-user 模式。

VIO4WD 最多支持 64 个转发实例（即一个 VF<->virtio 对），VFs 接收到数据包，然后发送到对应的 virtio 后端，反之亦然。中继原理可以从 NICs 和 virtio 网络驱动程序提供的技术中获益。NIC 可以下放部分或全部网络功能，而 virtio 支持 VM 实时迁移，并且对底层硬件不可见。

当前的热迁移功能是不支持预测虚拟机热迁移时间的，能提供热迁移相关状态信息的只有info migrate指令。热迁移有时会消耗很长时间，而用户想要知道能否完成热迁移，或者需要花多少时间来完成热迁移。为了实现这个目的，我实现了一个写内存负载发生器（mem_writer）并为 QEMU 增加了一个 qapi。目前测试下来实际消耗时间与预测时间相差 3% 到 10%。目前该方法仍有较大的限制，该实验：

1. 只讨论 RAM；
2. 只讨论 pre-copy；

脏页生成速率的问题目前无法解决，该实验只能作为参考，无实际意义。