Ubuntu 20.04 部署 OpenDaylight SDN 控制器

发布时间:2026/9/19 12:22:25
Ubuntu 20.04 部署 OpenDaylight SDN 控制器 简介面向SDN初学者与网络工程师这份教程详解Ubuntu 20.0.4系统下OpenDaylight控制器的完整部署过程。内容从实验背景与目的切入先介绍OpenFlow协议在SDN中的作用再分步讲解更新系统软件源、安装并配置JDK 8环境变量JAVA_HOME、java -version验证、添加Maven仓库与GPG密钥、校验Maven版本、从官网下载OpenDaylight并解压启动以及通过Karaf安装REST API、L2 Switch、OpenFlow插件等组件。教程还设计了Mininet生成拓扑连接OpenDaylight并执行ping命令抓包的验证环节帮助读者用Wireshark分析OpenFlow 1.3协议交互过程。文档以docx格式呈现共1个文件压缩包大小1.25MB资源已被1338人学习。教程源自真实实验记录每一步都配有执行命令与用途说明整体为可复现的实验手册并提及软件源更新失败、Maven仓库不可用等常见问题的处理思路适合需要完成SDN课程实验、撰写网络实验报告的高校学生也适合希望快速搭建OpenDaylight开发环境的网络工程师。对于SDN入门而言这份资料既能巩固OpenFlow协议原理也能积累控制器部署实战经验。1. Ubuntu 20.04 跑通 OpenDaylight 的入口先看版本与运行形态标题写的是“Ubuntu20.0.4”业内通常指 Ubuntu 20.04 LTS。OpenDaylight下称 ODL是一套 SDN 控制器实际是一个运行在 Karaf 容器里的 Java 程序安装方式不像普通软件那样apt install完事而是下载发行包、配好 JDK、启动容器、再安装功能组件。安装本身不复杂真正的门槛在版本对齐ODL 各发行版要求的 Java 版本不同Ubuntu 20.04 默认源里的 JDK 又不止一个装错版本会在启动阶段直接报类加载错误。本文从环境检查开始把“下载、启动、验证、排错、服务化”一条链路写清楚适合第一次在 20.04 上部署 ODL 的网络工程师也适合后续要接 OpenFlow 交换机做实验的开发者。2. 安装 OpenDaylight 前在 Ubuntu 20.04 上核对 JDK、内存与端口2.1 Java 版本先对齐再谈下载ODL 本质是跑在 Karaf 里的 Java 应用JDK 版本直接影响能不能启动。较新的 ODL 主版本普遍要求 JDK 11 及以上JDK 8 只能跑老发行版Ubuntu 20.04 系统自带的 openjdk-8 如果直接拿来启动新版 ODL最常见的报错是UnsupportedClassVersionError还有一类表现为 Karaf 启动到一半进程直接退出日志里只留一行 Java 版本不满足的提示。常见做法是先明确你要装的 ODL 版本再去官网发行说明里核对对应的 JDK然后用 apt 装指定版本避免多个 JDK 混用把JAVA_HOME指向错误位置。sudo apt update sudo apt install -y openjdk-11-jdk java -version readlink -f $(which java)第一段命令安装 openjdk-11-jdk第二段验证当前生效的 Java 版本第三段readlink找出 java 可执行文件的真实路径。这个真实路径后面要写成JAVA_HOME因为很多 ODL 启动脚本只认JAVA_HOME/bin/java不认 PATH 里的软链路径。装完建议把环境变量写进 profileecho export JAVA_HOME/usr/lib/jvm/java-11-openjdk-amd64 | sudo tee /etc/profile.d/java.sh echo export PATH\$JAVA_HOME/bin:\$PATH | sudo tee -a /etc/profile.d/java.sh source /etc/profile.d/java.sh这里把JAVA_HOME指向 openjdk-11 的安装目录PATH 追加到$JAVA_HOME/bin写在/etc/profile.d/java.sh里保证所有登录用户都能读到。注意echo里的\$PATH必须转义否则写入文件时变量会被当场展开成当前 PATH 值后面登录时 PATH 里就没有 Java 目录了。常见误用是把JAVA_HOME写进某个用户自己的.bashrc然后用 systemd 启动 ODL 时报找不到 Java原因就是 systemd 默认不加载用户 shell 配置文件。2.2 内存、磁盘与系统架构检查ODL 是内存大户一个只装了 OpenFlow 和 RESTCONF 基础功能的实例启动后 Java 进程常驻内存 2GB 左右如果还要跑拓扑服务和多个南向插件建议空闲内存不低于 4GB。在 VMware 或 VirtualBox 里用 Ubuntu 20.04 虚拟机跑 ODL 时虚拟机内存至少分配 4GB否则 Karaf 启动到一半会被系统 OOM 杀掉卡在“进程刚起来就消失”的状态。磁盘方面ODL 发行包解压后约 1GBdata/log和data/tmp目录会持续写日志给/opt或安装目录所在分区留 10GB 空间比较稳妥。free -h df -h /opt uname -mfree -h看可用内存df -h /opt确认安装目录所在磁盘剩余空间uname -m输出x86_64表示 64 位 x86 架构输出aarch64则是 ARM 架构。ODL 官方发行包同时提供 x86_64 和 ARM 版本在树莓派、RK3588 这类 ARM 开发板上跑时记得选对应架构的包ARM 上部分第三方 feature 没有预编译只能自己编译源码这一点比 x86 要麻烦不少。2.3 端口清单与占用检查ODL 固定监听几个端口安装前先确认这些端口没有被占用省得后面排查半天。最核心的是 8101 和 8181 两个8101 是 Karaf SSH 控制台8181 是 HTTP 管理界面和 RESTCONF API 入口。OpenFlow 南向协议默认端口是 6633但多数 ODL 发行版要求显式监听 6653实际用哪个以配置为准。端口用途默认协议8101Karaf SSH 控制台SSH8181HTTP 管理界面 / RESTCONFHTTP6633 / 6653OpenFlow 控制器监听TCP8080部分版本管理服务备用HTTP检查端口占用用ss -ltnp只看感兴趣的几个端口ss -ltnp | grep -E 8101|8181如果输出为空说明端口空闲。如果已有进程占用ss输出里能看到进程 PID配合ps -p PID -o comm确认是什么程序占着。常见占用来源是之前装过的 ZooKeeper、其他 Karaf 实例或系统自带的端口映射服务优先级高的处理办法是停掉旧进程而不是硬改 ODL 端口因为改端口要同时改etc/jetty.xml和etc/org.apache.karaf.shell.cfg多处配置容易漏。3. 下载 OpenDaylight 发行包并启动 Karaf 容器3.1 选对发行包类型用 wget 拉取ODL 的发布包在官网 Release 页面每个版本提供一个.tar.gz格式的发行包文件名通常类似opendaylight-版本号.tar.gz。注意发行包和源码包要区分源码包是给二次开发用的部署控制器直接下载二进制发行包即可。常见误区是去 Ubuntu 源里apt search opendaylight20.04 官方源里的 ODL 版本老旧和当下 OpenFlow 交换机固件的兼容性不一定好建议直接下载官网对应版本的包。cd /opt sudo wget -O opendaylight.tgz 官网发行包链接 sudo tar xf opendaylight.tgz sudo ls -d opendaylight-*/下载到/opt下用-O统一命名成opendaylight.tgz方便后续脚本引用然后解压。tar解压出的目录名带版本号例如opendaylight-0.18.0之类这就是 ODL 的家目录。解压后先别急着启动确认一下bin/karaf文件有执行权限权限不对时启动脚本会报Permission denied这类问题在把包解压到挂载盘时很常见。3.2 创建专用用户并设置目录属主不推荐用 root 直接跑 ODL。Java 进程一旦被攻破root 权限会让影响范围扩大很多而且 ODL 会在data目录下持续写入日志和临时文件以 root 运行后这些文件属主全是 root后续切回普通用户维护时清理日志要反复加sudo。常见做法是创建专用系统用户sudo useradd -r -m -s /bin/bash odl sudo chown -R odl:odl /opt/opendaylight-* sudo -u odl /opt/opendaylight-*/bin/karafuseradd -r创建系统用户-m同时建 home 目录-s /bin/bash保证能登录调试。chown -R把整个 ODL 目录属主改成odl否则首次启动时 Karaf 写不了data/tmp和data/log下的文件。最后一条命令用sudo -u odl切换到专用用户身份前台启动 Karaf前台启动能看到完整启动日志适合第一次部署时观察是否报错。3.3 首次启动后先装 feature再重启加载bin/karaf启动后终端进入 Karaf 控制台提示符变成opendaylight-userroot。看到提示符不代表 ODL 已经就绪因为控制器核心功能是按 feature 模块加载的默认只启动了一个容器壳OpenFlow 插件、RESTCONF 接口都要手动安装。这一步是新手最容易卡住的地方启动后访问 8181 端口发现打不开以为安装失败实际只是没装 HTTP 相关 feature。feature:install odl-restconf odl-openflowplugin-flow-services这条命令在 Karaf 控制台里执行安装 RESTCONF 北向接口和 OpenFlow 流表服务组件。feature:install是 Karaf 的统一安装命令注意拼写是feature单数写成features:install会报命令不存在。安装过程中控制台有可能短暂无响应这是 Karaf 在下载并解析依赖 bundle属正常现象。装完执行shutdown -r重启容器让所有 feature 完整加载然后退出控制台shutdown -r重启后再次进入控制台输入feature:list -i可以查看已安装的 feature 列表确认odl-restconf和odl-openflowplugin-flow-services都在其中。如果以后每次启动都想自动加载这些模块可以把 feature 列表写进etc/org.apache.karaf.features.cfg的featuresBoot配置项用逗号分隔这样免去每次手动安装。手动安装的方式适合先验证功能验证通过后再固化到配置里。3.4 清理 Karaf 缓存的两个场景ODL 跑久了或者升级 feature 之后偶尔会出现模块加载不全、控制台命令找不到的情况常见处理是清缓存重启。Karaf 默认缓存目录是data/cache里面存放已解析的 bundle 状态强制清空可以用sudo -u odl /opt/opendaylight-*/bin/karaf cleanclean参数会在启动时删除缓存并重新解析所有 feature启动时间比正常启动长不少。需要知道的是clean不是常规操作只在怀疑缓存损坏时才用。平时遇到 feature 装了没生效先执行feature:list -i看列表确认已安装再考虑重启动不动就clean会掩盖真正的问题比如写错了 feature 名或版本不匹配。4. 验证 OpenDaylight 服务状态并处理安装排错4.1 从 SSH 控制台检查模块运行状态Karaf 启动完成后8101 端口开始监听 SSH。用 SSH 客户端连接时用户名和默认密码都是karaf连接命令如下ssh -p 8101 karaflocalhost提示密码时输入karaf即可进入控制台。注意 8101 的 SSH 是 Karaf 内置的和 Ubuntu 系统的 OpenSSH 没有关系即使系统 sshd 没启动也不影响这个端口。进入控制台后检查两个东西已经安装的 feature 和 OpenFlow bundle 的运行状态。feature:list -i bundle:list | grep -i openflowfeature:list -i只显示已安装的 feature确认odl-openflowplugin-flow-services在列表里bundle:list | grep -i openflow查看 OpenFlow 相关 bundle 的状态第一列是 bundle ID状态列应该是Active。如果看到Resolved或Installed说明 bundle 没启动成功多半是依赖缺失或端口被占。生产环境建议修改etc/users.properties里的默认密码否则任何能访问 8101 端口的人都能直接拿到 Karaf 控制台权限这个文件里把karaf karaf, group这行改成强密码即可。4.2 用 HTTP 和 curl 探测 RESTCONF 是否可用SSH 控制台确认的是模块加载状态业务上最关心的是北向接口能不能调。ODL 的 RESTCONF 服务监听 8181浏览器访问http://服务器IP:8181/index.html可以看到登录页面默认管理员账号密码是admin/admin。也可以不看页面直接 curl 探测 APIcurl -u admin:admin http://localhost:8181/restconf/operational/network-topology:network-topology返回 200 状态码和一串 JSON 数据说明 RESTCONF 服务正常返回 401 是认证失败检查账号密码返回 404 说明 URL 路径不对不同版本的 RESTCONF 模块挂载路径略有差异。这条 curl 命令同时也是后续写自动化脚本时的探活命令判断 ODL 是否存活比单纯看端口要可靠端口在监听但 RESTCONF 模块没加载完的情况并不少见。4.3 安装期常见报错与排查路径安装过程中遇到最多的是下面几类问题按出现频率排序JAVA_HOME 指向错误或 JDK 版本不对。启动脚本找 Java 失败时报Unable to find any Javadoc或直接提示JAVA_HOME没有指向 JDK此时回到第 2 章检查/etc/profile.d/java.sh和bin/karaf脚本里的JAVA_HOME变量。如果启动过程报UnsupportedClassVersionError是 JDK 版本低于 ODL 要求换更高版本 JDK 即可。8101 端口连不上。Ubuntu 服务器上执行ssh -p 8101提示 Connection refused先确认 Karaf 进程活着ps -ef | grep karaf如果进程存在但端口没监听大概率是 Karaf 还在启动过程中等待 1 到 2 分钟再试。进程都没了就看内存是否够dmesg | tail里有 OOM 记录就可以确认。feature 安装报 “Command not found”。输入feature:install提示找不到命令通常是 Karaf 控制台没完全就绪等待几秒再输入或者执行shell:init重新初始化命令补全。更隐蔽的情况是拼写错误feature和features只差一个字母命令却完全不同。日志定位。所有安装期问题最终都集中在日志里排查ODL 日志目录是/opt/opendaylight-*/data/log/核心文件是karaf.log。也可以在 Karaf 控制台里执行log:tail实时跟踪日志输出。排查顺序建议是先看进程在不在再看端口通不通再看日志里最后的异常堆栈最后回到 feature 安装列表确认模块状态。5. 把 OpenDaylight 注册成 systemd 服务开机自启并接管日志前面的启动方式适合调试生产环境要把 ODL 交给 systemd 管理。相比自己写启动脚本systemd 的好处是崩溃自动拉起、开机自动启动、日志统一进 journalctl用一套命令就能查状态和日志。新建/etc/systemd/system/opendaylight.service[Unit] DescriptionOpenDaylight SDN Controller Afternetwork.target [Service] Typesimple Userodl Groupodl WorkingDirectory/opt/opendaylight EnvironmentJAVA_HOME/usr/lib/jvm/java-11-openjdk-amd64 ExecStart/opt/opendaylight/bin/karaf run Restarton-failure RestartSec30 SuccessExitStatus143 [Install] WantedBymulti-user.targetExecStart用了karaf run这是 Karaf 4 提供的前台运行模式systemd 必须管理前台进程才能可靠判断服务存活如果写成不带run的bin/karafKaraf 会 fork 出子进程后父进程退出systemd 会认为服务启动失败。SuccessExitStatus143表示进程被 SIGTERM 结束时 systemd 不把它当错误因为systemctl stop会主动发 SIGTERM 给 Java 进程。Environment不能省systemd 不加载用户的.bashrc和/etc/profile.d非 root 用户的JAVA_HOME必须显式写在这里Userodl也要和安装时创建的用户保持一致。启动并设置开机自启sudo systemctl daemon-reload sudo systemctl enable --now opendaylight systemctl status opendaylight journalctl -u opendaylight -fenable --now同时完成开机自启和立即启动。status查看服务运行状态和最近日志journalctl -u opendaylight -f实时跟踪 ODL 输出。相比直接看data/log/karaf.logjournalctl 的优势是重启轮转后日志不会丢。如果服务反复重启用journalctl -u opendaylight -u 30看最近 30 行日志定位原因常见问题是WorkingDirectory写错导致 ODL 找不到etc目录、Userodl对安装目录没有写权限以及JAVA_HOME路径和实际 JDK 安装位置不一致。服务托管后的验证方式和第 4 章一样先看端口再 curl RESTCONF。唯一区别是确认 systemd 把进程真正拉起来了执行systemctl status opendaylight看到Active: active (running)后再测 8101 和 8181。后续要调整 JVM 内存编辑/opt/opendaylight/bin/setenv里的KARAF_OPTS-Xmx4G并重启服务即可。本文还有配套的精品资源点击获取