1. 为什么要在虚拟化环境里跑 Tungsten Fabric如果你正在接触 SDN 控制器、云网融合或者多租户网络虚拟化Tungsten Fabric 这个名字大概率绕不开。它最早由 Juniper 开源后来捐给 Linux 基金会核心定位是一套面向云原生和多云场景的网络虚拟化与控制平面方案能同时管理虚拟机和容器的工作负载提供租户隔离、安全策略、路由分发、负载均衡等一整套能力。说白了它想解决的就是在共享的物理网络上给每个租户切出一张独立、可编程、可策略化的虚拟网络这件事。但真到动手环节很多人第一步就卡住了。Tungsten Fabric 的完整部署通常需要一组节点控制节点、计算节点、网关节点还要配 SDN 网关、vRouter 内核模块、消息队列、数据库等一堆组件。如果你只是想先把它跑起来看看架构长什么样、控制台长什么样、vRouter 怎么和控制器握手直接上物理机或者云主机集群成本高、周期长、清理麻烦。这时候用 Vagrant 在本地拉起一套虚拟机集群就是性价比最高的选择。Vagrant 的价值在于它把虚拟机编排这件事变成了一个可版本化、可复现的配置文件。你写一个 Vagrantfile声明要几台机器、什么系统、多少内存、网络怎么连然后一条vagrant up就能把整套环境拉起来。对 Tungsten Fabric 这种多节点、组件多、依赖复杂的系统来说Vagrant 让你可以在几分钟内得到一个干净、隔离、随时能推倒重来的实验环境。这篇文章就是围绕用 Vagrant 安装 Tungsten Fabric这个具体场景把选型理由、环境准备、配置细节、安装流程、踩坑排查和验证方法完整讲一遍适合刚接触 SDN 控制器的运维和开发同学也适合想快速搭个实验环境做验证的老手。需要先说明一点Tungsten Fabric 的版本迭代比较快不同版本对内核、Docker、Python 版本的要求差异不小。本文基于社区里比较常见的单控制节点加多计算节点的实验拓扑来展开具体版本号我会在关键位置标注你实际操作时以自己选定的发行版文档为准。另外整套环境对宿主机资源有要求建议至少 16GB 内存、4 核以上 CPU、50GB 以上空闲磁盘否则跑起来会非常吃力。2. 宿主机环境与 Vagrant 基础准备2.1 虚拟化后端的选择VirtualBox 还是 libvirtVagrant 本身只是个编排层真正干活的是它背后的虚拟化 provider。最常见的两个选择是 VirtualBox 和 libvirt配合 KVM/QEMU。这两者在 Tungsten Fabric 实验环境里的表现差别挺明显我先把结论摆出来Linux 宿主机优先用 libvirtWindows 或 macOS 宿主机基本只能用 VirtualBox。VirtualBox 的优点是跨平台、安装简单、图形界面友好缺点是网络性能和嵌套虚拟化支持一般。Tungsten Fabric 的 vRouter 需要在内核里做转发对网络性能敏感VirtualBox 的 NAT 和 host-only 网络在高负载下容易成为瓶颈。libvirt 基于 KVM性能接近原生网络模型也更灵活支持桥接、NAT、隔离网络等多种模式适合做多节点实验。如果你在 Linux 上安装 libvirt 相关组件的命令大致如下以常见的 Debian 系为例sudo apt update sudo apt install -y qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils sudo apt install -y vagrant vagrant-libvirt装完之后用vagrant plugin list确认vagrant-libvirt插件已经就位。如果没装上可以手动执行vagrant plugin install vagrant-libvirt。这里有个坑vagrant-libvirt插件对 Ruby 版本和 libvirt 开发库有依赖如果报编译错误先装libvirt-dev和ruby-dev再重试。Windows 用户就老老实实用 VirtualBox记得同时装好 VirtualBox Extension Pack否则 USB 和部分网络功能会受限。macOS 用户如果用的是 Apple Silicon要注意 VirtualBox 对 ARM 架构的支持一直不太理想这种情况建议考虑用 QEMU 或者干脆找一台 x86 的 Linux 机器来做实验。2.2 Vagrant box 的挑选与镜像来源Vagrant 的虚拟机镜像叫 box。Tungsten Fabric 对操作系统有明确要求社区文档里常见的是 Ubuntu 18.04/20.04 和 CentOS 7。选 box 的时候有几个硬性指标要看内核版本要匹配 vRouter 内核模块的编译要求太新或太旧都可能编译失败。要能方便地安装 Docker因为 Tungsten Fabric 的很多组件是容器化部署的。网络配置要支持多网卡实验拓扑里通常需要管理网、控制网、数据网分离。我一般会选官方的ubuntu/bionic64或者generic/ubuntu2004这类维护活跃的 box。选之前先看一眼 box 的更新时间和下载量太冷门的 box 往往缺驱动或者网络配置有坑。可以用下面的命令查看和添加 boxvagrant box list vagrant box add generic/ubuntu2004提示box 下载速度受网络影响较大如果卡住可以配置国内镜像源或者提前用下载工具把 box 文件拉下来再用vagrant box add指定本地文件路径添加。2.3 资源规划别让内存成为瓶颈多节点实验最容易被低估的就是内存。Tungsten Fabric 的控制节点要跑 Cassandra、Zookeeper、RabbitMQ、Redis、Kafka、控制器本身等一堆服务光控制节点就建议给 8GB 内存。每个计算节点跑 vRouter 和若干测试容器建议 4GB 起步。如果你规划一控两算那就是 84416GB再加上宿主机系统本身的开销宿主机至少要有 24GB 内存才比较从容。CPU 方面每个节点给 2 核基本够用但编译 vRouter 内核模块的时候会吃满 CPU建议宿主机留出余量。磁盘用动态分配的虚拟磁盘就行但要注意 Vagrant 默认的磁盘扩容比较麻烦最好在 Vagrantfile 里就把磁盘大小设够比如每节点 20GB。下面这张表是我常用的一个资源分配参考你可以根据自己的机器情况调整节点角色内存CPU磁盘说明控制节点8GB2核20GB跑数据库、消息队列、控制器计算节点4GB2核20GB跑 vRouter 和测试负载网关节点4GB2核20GB可选做跨子网转发宿主机24GB4核50GB留足余量给虚拟化开销3. 编写 Vagrantfile把多节点拓扑声明出来3.1 网络模型设计三张网卡怎么分Tungsten Fabric 的实验环境里网络划分是核心。通常需要三类网络管理网用于 SSH 和 API 访问控制网用于控制器和 vRouter 之间的 XMPP 通信数据网用于租户流量的 overlay 转发。在 Vagrant 里我们可以用 private network 来模拟这些隔离网络。一个常见的做法是给每个节点配三块网卡第一块是 Vagrant 默认的 NAT 网卡用于访问外网下载依赖第二块是管理网网段比如 192.168.56.0/24第三块是控制/数据网网段比如 192.168.100.0/24。这样控制器和 vRouter 之间的通信走内网不会和外网流量混在一起。在 Vagrantfile 里private network 的配置大概长这样config.vm.network private_network, ip: 192.168.56.10, virtualbox__intnet: mgmt config.vm.network private_network, ip: 192.168.100.10, virtualbox__intnet: ctrl用 libvirt 的话写法略有不同通常用libvirt__network_name指定网络。这里要注意VirtualBox 的intnet是内部网络只有同一 intnet 的机器能互通正好用来做隔离。libvirt 则更推荐预先定义好网络再引用。3.2 用循环批量定义节点手写每个节点的配置既啰嗦又容易出错Vagrantfile 支持 Ruby 语法可以用循环来批量生成。下面是一个简化后的结构示例nodes [ { name: tf-control, ip: 192.168.56.10, ctrl_ip: 192.168.100.10, mem: 8192, cpu: 2 }, { name: tf-compute1, ip: 192.168.56.11, ctrl_ip: 192.168.100.11, mem: 4096, cpu: 2 }, { name: tf-compute2, ip: 192.168.56.12, ctrl_ip: 192.168.100.12, mem: 4096, cpu: 2 } ] Vagrant.configure(2) do |config| config.vm.box generic/ubuntu2004 nodes.each do |node| config.vm.define node[:name] do |n| n.vm.hostname node[:name] n.vm.network private_network, ip: node[:ip] n.vm.network private_network, ip: node[:ctrl_ip] n.vm.provider virtualbox do |vb| vb.memory node[:mem] vb.cpus node[:cpu] end end end end这段配置里每个节点拿到两个私有 IP一个走管理网段一个走控制网段。hostname 设成节点名方便后面用 Ansible 或者脚本批量操作。实际用的时候你还可以在循环里加上 provision 脚本让节点起来后自动装依赖、配 hosts、关防火墙。3.3 主机名解析与免密登录的预处理Tungsten Fabric 的组件之间大量依赖主机名通信所以每个节点的/etc/hosts必须能正确解析所有节点。最省事的办法是在 provision 阶段统一写入。可以在 Vagrantfile 里加一段 shell provisioncat /etc/hosts EOF 192.168.56.10 tf-control 192.168.56.11 tf-compute1 192.168.56.12 tf-compute2 EOF免密登录也是同理控制节点要能 SSH 到计算节点做部署提前把公钥分发好能省很多事。Vagrant 默认用vagrant用户和 insecure_private_key你可以直接用这个密钥做节点间互信也可以生成新密钥再分发。我一般会在 provision 里生成一对新密钥把公钥追加到所有节点的 authorized_keys私钥放在控制节点上。注意生产环境绝对不要用默认的 insecure key实验环境图省事可以但心里要清楚这只是临时方案。4. 安装 Tungsten Fabric从依赖到控制器就绪4.1 系统层依赖内核模块编译的前置条件Tungsten Fabric 的 vRouter 是一个内核模块编译它需要内核头文件和编译工具链。在 Ubuntu 上这一步经常出问题因为默认安装的内核头文件版本可能和当前运行内核不一致。稳妥的做法是先确认内核版本再装对应版本的头文件uname -r sudo apt install -y linux-headers-$(uname -r) build-essential dkms如果linux-headers-$(uname -r)找不到说明软件源里没有对应版本这时候要么升级内核要么换一个头文件齐全的 box。这是新手最容易卡住的地方之一报错信息通常是找不到内核头文件或者模块编译失败看到这类错误先查内核版本匹配问题。除了内核头文件还需要 Docker。Tungsten Fabric 的很多组件以容器形式运行Docker 版本建议用 19.03 或 20.10 这类经过验证的稳定版。安装完 Docker 后记得把当前用户加入 docker 组否则每次都要 sudosudo usermod -aG docker $USER newgrp docker4.2 获取部署脚本与配置文件Tungsten Fabric 社区提供了一套基于 Ansible 的部署工具通常放在一个叫tf-dev-env或者类似名字的仓库里。部署的核心是一个 inventory 文件加一组 playbook。inventory 文件里要声明控制节点、计算节点、网关节点的主机名和 IP以及各种角色参数。一个简化的 inventory 结构大概是这样[control] tf-control ansible_host192.168.56.10 [compute] tf-compute1 ansible_host192.168.56.11 tf-compute2 ansible_host192.168.56.12 [all:vars] ansible_uservagrant ansible_ssh_private_key_file~/.ssh/id_rsa这里的关键是把节点角色分清楚。控制节点承担数据库、消息队列、控制器等角色计算节点只跑 vRouter。如果资源紧张也可以把控制和计算合在一台机器上做 all-in-one但那样就失去了多节点实验的意义vRouter 和控制器的交互过程看不清楚。4.3 执行部署分阶段推进而不是一把梭Ansible playbook 通常支持按标签分阶段执行。我的建议是不要一上来就跑全量而是分三步走先做基础环境准备再装控制平面最后装计算节点。这样出问题的时候容易定位。第一步基础准备包括装依赖、配 hosts、调内核参数、加载必要模块。第二步控制平面部署会拉起 Cassandra、Zookeeper、RabbitMQ、Redis、Kafka 和控制器容器。这一步耗时最长也最容易出问题因为容器镜像拉取、数据库初始化都可能失败。第三步计算节点部署编译并加载 vRouter 内核模块启动 vRouter agent让它去连控制器。执行命令大致是ansible-playbook -i inventory site.yml --tags prepare ansible-playbook -i inventory site.yml --tags control ansible-playbook -i inventory site.yml --tags compute每跑完一步都去对应节点上用docker ps看看容器是不是都起来了用docker logs看关键容器有没有报错。控制节点上如果 Cassandra 没起来后面的控制器肯定起不来所以顺序不能乱。4.4 容器镜像拉取慢的应对办法部署过程中最耗时的环节往往是拉容器镜像。Tungsten Fabric 的镜像数量多、体积大网络不好的话可能卡几十分钟甚至超时。几个应对思路一是提前在能访问镜像仓库的机器上把镜像拉下来导出成 tar 包再导入到各节点二是配置镜像加速三是把镜像仓库地址换成离你更近的源。导入镜像的命令是docker load -i tf-images.tar如果部署脚本支持指定本地镜像仓库那就更省事把所有镜像推到本地 registry然后让 inventory 指向这个 registry。这一步在离线环境里几乎是必须的。5. 部署后的验证与常见故障排查5.1 控制平面健康检查部署完成后第一件事是确认控制平面是否健康。控制节点上应该能看到一组容器在运行包括控制器、数据库、消息队列等。用docker ps看容器状态重点看有没有反复重启的容器。反复重启通常意味着配置错误或者依赖没就绪。控制器起来后可以通过它的 API 或者命令行工具查看节点注册情况。正常情况下计算节点上的 vRouter agent 会主动连上控制器控制器会把它标记为活跃。如果计算节点一直不出现八成是 XMPP 连接没建立起来要去计算节点上看 vRouter agent 的日志。5.2 vRouter 内核模块加载失败的排查链路vRouter 内核模块加载失败是最高频的问题我把完整的排查链路列一下你按顺序走先看dmesg有没有模块加载相关的报错比如版本不匹配、符号找不到。确认内核头文件版本和运行内核一致uname -r和/lib/modules下的目录要对得上。检查模块是否已经编译出来通常在/lib/modules/$(uname -r)/extra/或者源码目录下。用modprobe vrouter手动加载看具体报什么错。如果报模块签名问题检查 Secure Boot 是否开启实验环境可以在 BIOS 里关掉。如果报依赖模块缺失用modinfo vrouter看 depends 字段把依赖模块先加载上。这个链路走下来基本能覆盖九成以上的模块加载问题。我遇到过最隐蔽的一次是内核小版本升级后头文件没跟着更新表面看版本号一样实际编译出来的模块和运行内核不匹配最后重装头文件才解决。5.3 节点间通信与防火墙多节点环境里节点之间的端口必须通。Tungsten Fabric 用到的端口不少XMPP、HTTP、数据库、消息队列各有各的端口。Ubuntu 默认可能开着 ufwCentOS 默认开着 firewalld实验环境里最省事的做法是直接关掉防火墙或者把相关网段全部放行。sudo systemctl stop ufw sudo systemctl disable ufw关防火墙只是实验环境的权宜之计真实环境一定要按最小权限原则精确放行。另外要确认net.ipv4.ip_forward是开启的否则转发不通sudo sysctl -w net.ipv4.ip_forward1这个参数最好写进/etc/sysctl.conf持久化不然重启就丢了。5.4 用测试负载验证 overlay 网络控制平面健康、vRouter 加载成功只能说明环境搭起来了真正要验证的是 overlay 网络能不能通。做法是在两个计算节点上各起一个测试容器接到同一个虚拟网络里然后互相 ping。如果通说明 vRouter 的隧道转发、控制器的路由下发都正常。如果 ping 不通排查顺序是先看两个 vRouter 有没有建立隧道再看控制器有没有把对方的路由下发过来最后看安全策略有没有把流量挡掉。Tungsten Fabric 默认策略可能比较严格实验阶段可以先放宽策略确认连通性再逐步收紧。6. 几个让我印象深刻的坑和应对经验6.1 时间不同步导致证书校验失败这个坑很隐蔽。虚拟机挂起再恢复之后系统时间可能和宿主机偏差很大而 Tungsten Fabric 组件之间用证书做认证证书校验对时间敏感。时间偏差超过阈值组件之间就会互相拒绝连接日志里报的是证书错误很容易误导人去查证书配置。解决办法是每个节点都装并启用时间同步服务确保集群内时间一致。sudo apt install -y chrony sudo systemctl enable --now chrony6.2 磁盘空间被容器日志悄悄吃满跑一段时间后控制节点可能突然各种服务异常查半天发现是磁盘满了。Docker 的容器日志默认不限制大小Tungsten Fabric 的组件日志量又不小几天就能把 20GB 磁盘吃满。两个办法一是给 Docker 配置日志轮转在/etc/docker/daemon.json里加 log-driver 和 log-opts二是定期清理无用镜像和停止的容器。{ log-driver: json-file, log-opts: { max-size: 50m, max-file: 3 } }改完重启 Docker 生效。这个配置建议在环境搭好之后就加上别等磁盘满了再补救。6.3 快照与重建把实验环境当代码管理Vagrant 有个很好用的能力是快照。在关键节点做完基础配置、装好依赖之后打个快照后面实验搞砸了直接回滚比重新vagrant up快得多。vagrant snapshot save tf-control base-ready vagrant snapshot restore tf-control base-ready更进一步把 Vagrantfile、inventory、provision 脚本全部纳入版本控制整个实验环境就变成了可复现的代码。换一台机器clone 下来vagrant up就能得到一模一样的环境。这是我在做多轮实验时最依赖的工作方式强烈建议你也这么干。6.4 资源超配导致宿主机卡死最后一个坑是资源规划。我见过有人在一台 16GB 的笔记本上开一控三算结果宿主机自己先卡死了。虚拟化是有开销的给虚拟机的内存总和不能接近宿主机物理内存。留出至少 4GB 给宿主机系统再考虑虚拟机的分配。如果实在资源紧张就减少计算节点数量或者把控制节点和计算节点合并先跑通流程再说。这套用 Vagrant 搭 Tungsten Fabric 实验环境的方法我自己反复用过很多次每次换机器或者换版本都会重新走一遍。它最大的价值不是省了买服务器的钱而是让整个环境变得可丢弃、可重建、可版本化。你可以在上面大胆试各种配置搞坏了回滚快照或者重新 up 就行这种心理上的轻松感才是做实验最需要的状态。
1. 为什么要在虚拟化环境里跑 Tungsten Fabric如果你正在接触 SDN 控制器、云网融合或者多租户网络虚拟化Tungsten Fabric 这个名字大概率绕不开。它最早由 Juniper 开源后来捐给 Linux 基金会核心定位是一套面向云原生和多云场景的网络虚拟化与控制平面方案能同时管理虚拟机和容器的工作负载提供租户隔离、安全策略、路由分发、负载均衡等一整套能力。说白了它想解决的就是在共享的物理网络上给每个租户切出一张独立、可编程、可策略化的虚拟网络这件事。但真到动手环节很多人第一步就卡住了。Tungsten Fabric 的完整部署通常需要一组节点控制节点、计算节点、网关节点还要配 SDN 网关、vRouter 内核模块、消息队列、数据库等一堆组件。如果你只是想先把它跑起来看看架构长什么样、控制台长什么样、vRouter 怎么和控制器握手直接上物理机或者云主机集群成本高、周期长、清理麻烦。这时候用 Vagrant 在本地拉起一套虚拟机集群就是性价比最高的选择。Vagrant 的价值在于它把虚拟机编排这件事变成了一个可版本化、可复现的配置文件。你写一个 Vagrantfile声明要几台机器、什么系统、多少内存、网络怎么连然后一条vagrant up就能把整套环境拉起来。对 Tungsten Fabric 这种多节点、组件多、依赖复杂的系统来说Vagrant 让你可以在几分钟内得到一个干净、隔离、随时能推倒重来的实验环境。这篇文章就是围绕用 Vagrant 安装 Tungsten Fabric这个具体场景把选型理由、环境准备、配置细节、安装流程、踩坑排查和验证方法完整讲一遍适合刚接触 SDN 控制器的运维和开发同学也适合想快速搭个实验环境做验证的老手。需要先说明一点Tungsten Fabric 的版本迭代比较快不同版本对内核、Docker、Python 版本的要求差异不小。本文基于社区里比较常见的单控制节点加多计算节点的实验拓扑来展开具体版本号我会在关键位置标注你实际操作时以自己选定的发行版文档为准。另外整套环境对宿主机资源有要求建议至少 16GB 内存、4 核以上 CPU、50GB 以上空闲磁盘否则跑起来会非常吃力。2. 宿主机环境与 Vagrant 基础准备2.1 虚拟化后端的选择VirtualBox 还是 libvirtVagrant 本身只是个编排层真正干活的是它背后的虚拟化 provider。最常见的两个选择是 VirtualBox 和 libvirt配合 KVM/QEMU。这两者在 Tungsten Fabric 实验环境里的表现差别挺明显我先把结论摆出来Linux 宿主机优先用 libvirtWindows 或 macOS 宿主机基本只能用 VirtualBox。VirtualBox 的优点是跨平台、安装简单、图形界面友好缺点是网络性能和嵌套虚拟化支持一般。Tungsten Fabric 的 vRouter 需要在内核里做转发对网络性能敏感VirtualBox 的 NAT 和 host-only 网络在高负载下容易成为瓶颈。libvirt 基于 KVM性能接近原生网络模型也更灵活支持桥接、NAT、隔离网络等多种模式适合做多节点实验。如果你在 Linux 上安装 libvirt 相关组件的命令大致如下以常见的 Debian 系为例sudo apt update sudo apt install -y qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils sudo apt install -y vagrant vagrant-libvirt装完之后用vagrant plugin list确认vagrant-libvirt插件已经就位。如果没装上可以手动执行vagrant plugin install vagrant-libvirt。这里有个坑vagrant-libvirt插件对 Ruby 版本和 libvirt 开发库有依赖如果报编译错误先装libvirt-dev和ruby-dev再重试。Windows 用户就老老实实用 VirtualBox记得同时装好 VirtualBox Extension Pack否则 USB 和部分网络功能会受限。macOS 用户如果用的是 Apple Silicon要注意 VirtualBox 对 ARM 架构的支持一直不太理想这种情况建议考虑用 QEMU 或者干脆找一台 x86 的 Linux 机器来做实验。2.2 Vagrant box 的挑选与镜像来源Vagrant 的虚拟机镜像叫 box。Tungsten Fabric 对操作系统有明确要求社区文档里常见的是 Ubuntu 18.04/20.04 和 CentOS 7。选 box 的时候有几个硬性指标要看内核版本要匹配 vRouter 内核模块的编译要求太新或太旧都可能编译失败。要能方便地安装 Docker因为 Tungsten Fabric 的很多组件是容器化部署的。网络配置要支持多网卡实验拓扑里通常需要管理网、控制网、数据网分离。我一般会选官方的ubuntu/bionic64或者generic/ubuntu2004这类维护活跃的 box。选之前先看一眼 box 的更新时间和下载量太冷门的 box 往往缺驱动或者网络配置有坑。可以用下面的命令查看和添加 boxvagrant box list vagrant box add generic/ubuntu2004提示box 下载速度受网络影响较大如果卡住可以配置国内镜像源或者提前用下载工具把 box 文件拉下来再用vagrant box add指定本地文件路径添加。2.3 资源规划别让内存成为瓶颈多节点实验最容易被低估的就是内存。Tungsten Fabric 的控制节点要跑 Cassandra、Zookeeper、RabbitMQ、Redis、Kafka、控制器本身等一堆服务光控制节点就建议给 8GB 内存。每个计算节点跑 vRouter 和若干测试容器建议 4GB 起步。如果你规划一控两算那就是 84416GB再加上宿主机系统本身的开销宿主机至少要有 24GB 内存才比较从容。CPU 方面每个节点给 2 核基本够用但编译 vRouter 内核模块的时候会吃满 CPU建议宿主机留出余量。磁盘用动态分配的虚拟磁盘就行但要注意 Vagrant 默认的磁盘扩容比较麻烦最好在 Vagrantfile 里就把磁盘大小设够比如每节点 20GB。下面这张表是我常用的一个资源分配参考你可以根据自己的机器情况调整节点角色内存CPU磁盘说明控制节点8GB2核20GB跑数据库、消息队列、控制器计算节点4GB2核20GB跑 vRouter 和测试负载网关节点4GB2核20GB可选做跨子网转发宿主机24GB4核50GB留足余量给虚拟化开销3. 编写 Vagrantfile把多节点拓扑声明出来3.1 网络模型设计三张网卡怎么分Tungsten Fabric 的实验环境里网络划分是核心。通常需要三类网络管理网用于 SSH 和 API 访问控制网用于控制器和 vRouter 之间的 XMPP 通信数据网用于租户流量的 overlay 转发。在 Vagrant 里我们可以用 private network 来模拟这些隔离网络。一个常见的做法是给每个节点配三块网卡第一块是 Vagrant 默认的 NAT 网卡用于访问外网下载依赖第二块是管理网网段比如 192.168.56.0/24第三块是控制/数据网网段比如 192.168.100.0/24。这样控制器和 vRouter 之间的通信走内网不会和外网流量混在一起。在 Vagrantfile 里private network 的配置大概长这样config.vm.network private_network, ip: 192.168.56.10, virtualbox__intnet: mgmt config.vm.network private_network, ip: 192.168.100.10, virtualbox__intnet: ctrl用 libvirt 的话写法略有不同通常用libvirt__network_name指定网络。这里要注意VirtualBox 的intnet是内部网络只有同一 intnet 的机器能互通正好用来做隔离。libvirt 则更推荐预先定义好网络再引用。3.2 用循环批量定义节点手写每个节点的配置既啰嗦又容易出错Vagrantfile 支持 Ruby 语法可以用循环来批量生成。下面是一个简化后的结构示例nodes [ { name: tf-control, ip: 192.168.56.10, ctrl_ip: 192.168.100.10, mem: 8192, cpu: 2 }, { name: tf-compute1, ip: 192.168.56.11, ctrl_ip: 192.168.100.11, mem: 4096, cpu: 2 }, { name: tf-compute2, ip: 192.168.56.12, ctrl_ip: 192.168.100.12, mem: 4096, cpu: 2 } ] Vagrant.configure(2) do |config| config.vm.box generic/ubuntu2004 nodes.each do |node| config.vm.define node[:name] do |n| n.vm.hostname node[:name] n.vm.network private_network, ip: node[:ip] n.vm.network private_network, ip: node[:ctrl_ip] n.vm.provider virtualbox do |vb| vb.memory node[:mem] vb.cpus node[:cpu] end end end end这段配置里每个节点拿到两个私有 IP一个走管理网段一个走控制网段。hostname 设成节点名方便后面用 Ansible 或者脚本批量操作。实际用的时候你还可以在循环里加上 provision 脚本让节点起来后自动装依赖、配 hosts、关防火墙。3.3 主机名解析与免密登录的预处理Tungsten Fabric 的组件之间大量依赖主机名通信所以每个节点的/etc/hosts必须能正确解析所有节点。最省事的办法是在 provision 阶段统一写入。可以在 Vagrantfile 里加一段 shell provisioncat /etc/hosts EOF 192.168.56.10 tf-control 192.168.56.11 tf-compute1 192.168.56.12 tf-compute2 EOF免密登录也是同理控制节点要能 SSH 到计算节点做部署提前把公钥分发好能省很多事。Vagrant 默认用vagrant用户和 insecure_private_key你可以直接用这个密钥做节点间互信也可以生成新密钥再分发。我一般会在 provision 里生成一对新密钥把公钥追加到所有节点的 authorized_keys私钥放在控制节点上。注意生产环境绝对不要用默认的 insecure key实验环境图省事可以但心里要清楚这只是临时方案。4. 安装 Tungsten Fabric从依赖到控制器就绪4.1 系统层依赖内核模块编译的前置条件Tungsten Fabric 的 vRouter 是一个内核模块编译它需要内核头文件和编译工具链。在 Ubuntu 上这一步经常出问题因为默认安装的内核头文件版本可能和当前运行内核不一致。稳妥的做法是先确认内核版本再装对应版本的头文件uname -r sudo apt install -y linux-headers-$(uname -r) build-essential dkms如果linux-headers-$(uname -r)找不到说明软件源里没有对应版本这时候要么升级内核要么换一个头文件齐全的 box。这是新手最容易卡住的地方之一报错信息通常是找不到内核头文件或者模块编译失败看到这类错误先查内核版本匹配问题。除了内核头文件还需要 Docker。Tungsten Fabric 的很多组件以容器形式运行Docker 版本建议用 19.03 或 20.10 这类经过验证的稳定版。安装完 Docker 后记得把当前用户加入 docker 组否则每次都要 sudosudo usermod -aG docker $USER newgrp docker4.2 获取部署脚本与配置文件Tungsten Fabric 社区提供了一套基于 Ansible 的部署工具通常放在一个叫tf-dev-env或者类似名字的仓库里。部署的核心是一个 inventory 文件加一组 playbook。inventory 文件里要声明控制节点、计算节点、网关节点的主机名和 IP以及各种角色参数。一个简化的 inventory 结构大概是这样[control] tf-control ansible_host192.168.56.10 [compute] tf-compute1 ansible_host192.168.56.11 tf-compute2 ansible_host192.168.56.12 [all:vars] ansible_uservagrant ansible_ssh_private_key_file~/.ssh/id_rsa这里的关键是把节点角色分清楚。控制节点承担数据库、消息队列、控制器等角色计算节点只跑 vRouter。如果资源紧张也可以把控制和计算合在一台机器上做 all-in-one但那样就失去了多节点实验的意义vRouter 和控制器的交互过程看不清楚。4.3 执行部署分阶段推进而不是一把梭Ansible playbook 通常支持按标签分阶段执行。我的建议是不要一上来就跑全量而是分三步走先做基础环境准备再装控制平面最后装计算节点。这样出问题的时候容易定位。第一步基础准备包括装依赖、配 hosts、调内核参数、加载必要模块。第二步控制平面部署会拉起 Cassandra、Zookeeper、RabbitMQ、Redis、Kafka 和控制器容器。这一步耗时最长也最容易出问题因为容器镜像拉取、数据库初始化都可能失败。第三步计算节点部署编译并加载 vRouter 内核模块启动 vRouter agent让它去连控制器。执行命令大致是ansible-playbook -i inventory site.yml --tags prepare ansible-playbook -i inventory site.yml --tags control ansible-playbook -i inventory site.yml --tags compute每跑完一步都去对应节点上用docker ps看看容器是不是都起来了用docker logs看关键容器有没有报错。控制节点上如果 Cassandra 没起来后面的控制器肯定起不来所以顺序不能乱。4.4 容器镜像拉取慢的应对办法部署过程中最耗时的环节往往是拉容器镜像。Tungsten Fabric 的镜像数量多、体积大网络不好的话可能卡几十分钟甚至超时。几个应对思路一是提前在能访问镜像仓库的机器上把镜像拉下来导出成 tar 包再导入到各节点二是配置镜像加速三是把镜像仓库地址换成离你更近的源。导入镜像的命令是docker load -i tf-images.tar如果部署脚本支持指定本地镜像仓库那就更省事把所有镜像推到本地 registry然后让 inventory 指向这个 registry。这一步在离线环境里几乎是必须的。5. 部署后的验证与常见故障排查5.1 控制平面健康检查部署完成后第一件事是确认控制平面是否健康。控制节点上应该能看到一组容器在运行包括控制器、数据库、消息队列等。用docker ps看容器状态重点看有没有反复重启的容器。反复重启通常意味着配置错误或者依赖没就绪。控制器起来后可以通过它的 API 或者命令行工具查看节点注册情况。正常情况下计算节点上的 vRouter agent 会主动连上控制器控制器会把它标记为活跃。如果计算节点一直不出现八成是 XMPP 连接没建立起来要去计算节点上看 vRouter agent 的日志。5.2 vRouter 内核模块加载失败的排查链路vRouter 内核模块加载失败是最高频的问题我把完整的排查链路列一下你按顺序走先看dmesg有没有模块加载相关的报错比如版本不匹配、符号找不到。确认内核头文件版本和运行内核一致uname -r和/lib/modules下的目录要对得上。检查模块是否已经编译出来通常在/lib/modules/$(uname -r)/extra/或者源码目录下。用modprobe vrouter手动加载看具体报什么错。如果报模块签名问题检查 Secure Boot 是否开启实验环境可以在 BIOS 里关掉。如果报依赖模块缺失用modinfo vrouter看 depends 字段把依赖模块先加载上。这个链路走下来基本能覆盖九成以上的模块加载问题。我遇到过最隐蔽的一次是内核小版本升级后头文件没跟着更新表面看版本号一样实际编译出来的模块和运行内核不匹配最后重装头文件才解决。5.3 节点间通信与防火墙多节点环境里节点之间的端口必须通。Tungsten Fabric 用到的端口不少XMPP、HTTP、数据库、消息队列各有各的端口。Ubuntu 默认可能开着 ufwCentOS 默认开着 firewalld实验环境里最省事的做法是直接关掉防火墙或者把相关网段全部放行。sudo systemctl stop ufw sudo systemctl disable ufw关防火墙只是实验环境的权宜之计真实环境一定要按最小权限原则精确放行。另外要确认net.ipv4.ip_forward是开启的否则转发不通sudo sysctl -w net.ipv4.ip_forward1这个参数最好写进/etc/sysctl.conf持久化不然重启就丢了。5.4 用测试负载验证 overlay 网络控制平面健康、vRouter 加载成功只能说明环境搭起来了真正要验证的是 overlay 网络能不能通。做法是在两个计算节点上各起一个测试容器接到同一个虚拟网络里然后互相 ping。如果通说明 vRouter 的隧道转发、控制器的路由下发都正常。如果 ping 不通排查顺序是先看两个 vRouter 有没有建立隧道再看控制器有没有把对方的路由下发过来最后看安全策略有没有把流量挡掉。Tungsten Fabric 默认策略可能比较严格实验阶段可以先放宽策略确认连通性再逐步收紧。6. 几个让我印象深刻的坑和应对经验6.1 时间不同步导致证书校验失败这个坑很隐蔽。虚拟机挂起再恢复之后系统时间可能和宿主机偏差很大而 Tungsten Fabric 组件之间用证书做认证证书校验对时间敏感。时间偏差超过阈值组件之间就会互相拒绝连接日志里报的是证书错误很容易误导人去查证书配置。解决办法是每个节点都装并启用时间同步服务确保集群内时间一致。sudo apt install -y chrony sudo systemctl enable --now chrony6.2 磁盘空间被容器日志悄悄吃满跑一段时间后控制节点可能突然各种服务异常查半天发现是磁盘满了。Docker 的容器日志默认不限制大小Tungsten Fabric 的组件日志量又不小几天就能把 20GB 磁盘吃满。两个办法一是给 Docker 配置日志轮转在/etc/docker/daemon.json里加 log-driver 和 log-opts二是定期清理无用镜像和停止的容器。{ log-driver: json-file, log-opts: { max-size: 50m, max-file: 3 } }改完重启 Docker 生效。这个配置建议在环境搭好之后就加上别等磁盘满了再补救。6.3 快照与重建把实验环境当代码管理Vagrant 有个很好用的能力是快照。在关键节点做完基础配置、装好依赖之后打个快照后面实验搞砸了直接回滚比重新vagrant up快得多。vagrant snapshot save tf-control base-ready vagrant snapshot restore tf-control base-ready更进一步把 Vagrantfile、inventory、provision 脚本全部纳入版本控制整个实验环境就变成了可复现的代码。换一台机器clone 下来vagrant up就能得到一模一样的环境。这是我在做多轮实验时最依赖的工作方式强烈建议你也这么干。6.4 资源超配导致宿主机卡死最后一个坑是资源规划。我见过有人在一台 16GB 的笔记本上开一控三算结果宿主机自己先卡死了。虚拟化是有开销的给虚拟机的内存总和不能接近宿主机物理内存。留出至少 4GB 给宿主机系统再考虑虚拟机的分配。如果实在资源紧张就减少计算节点数量或者把控制节点和计算节点合并先跑通流程再说。这套用 Vagrant 搭 Tungsten Fabric 实验环境的方法我自己反复用过很多次每次换机器或者换版本都会重新走一遍。它最大的价值不是省了买服务器的钱而是让整个环境变得可丢弃、可重建、可版本化。你可以在上面大胆试各种配置搞坏了回滚快照或者重新 up 就行这种心理上的轻松感才是做实验最需要的状态。
