尧图网页设计 
简介《媒体数据库与云存储》实验四实验报告是一份围绕OpenStack云计算与Swift对象存储实践撰写的完整实验记录面向高校媒体数据库、云计算及信息通信类专业学生尤其适合需要完成同类实验或想快速掌握云平台操作流程的读者。报告以中国传媒大学课程实验为背景依次展示了VMware中添加VMnet10虚拟网络、启动OpenStack主机、用demo账户登录Dashboard开展租户/用户管理以及创建Inst_demo云主机实例、查看网络拓扑结构等环节随后重点讲解了Swift客户端从认证、容器管理到上传本地对象和操作元数据的完整过程通过test和demo账户的实际操作读者还能直观感受OpenStack的认证机制与多租户权限模型。每个步骤均配有界面截图、命令行输入与返回结果方便读者逐步对照。资源包含一个PDF文件容量约3.66MB结构上从实验目的、环境准备到思考题完整覆盖查找方便。该资料已有84人浏览学习非常适合缺乏实验环境或想系统梳理OpenStack/Swift操作要点的同学文末思考题还比较了OpenStack与Windows、UNIX/Linux系统的差异有助于理解其架构优势与适用场景是一份既能用于个人复习、也可作为实验报告书写思路参考的课程实验材料。1. 一份 OpenStack Swift 实验报告能挖出多少生产级细节先说结论这份《媒体数据库与云存储》实验报告表面是学生作业实际是一个完整的 OpenStack 单机实验环境从零到 Swift 对象存储实战的记录。报告涵盖了 VMnet10 虚拟网络规划、Dashboard 云主机实例创建、Cirros/Fedora 双镜像联通性测试、Swift CLI 认证与容器/对象/元数据操作以及课后思考题里的 IaaS 架构和 Swift 环Ring原理。如果你正在备云计算课设、准备面试里 OpenStack 相关的问题或者单纯想抄一份验证过的实验步骤这份报告里 192.168.3.40、10.0.0.31、router-demo 这些连续可查的 IP 证据链会相当有用。下面我按「环境搭起来 → 实例跑起来 → 对象存进去 → 坑排干净 → 答案读明白」的顺序把这份报告拆开来讲。2. 从镜像恢复 OpenStack 主机VMnet10 与网络地址的那些事云计算实验的第一步永远是网络。报告里写的做法是在 VMware 中添加 VMnet10 虚拟网络然后从已有镜像生成 OpenStack 主机。这一步看着简单实际决定后面所有操作能不能联通。VMware 有三种常见的网络模式选错一个后面 OpenStack 的 Dashboard 就登不进去。它们的区别如下网络模式虚拟机与外网关系虚拟机间通信宿主机访问虚拟机典型用途NAT共享宿主机 IP 访问外网支持需要端口映射虚拟机要上外网装软件Bridged与宿主机在同一广播域支持直接同网段访问虚拟机需接入局域网Host-OnlyVMnet10不提供外网访问支持支持靠虚拟网卡纯内网实验环境报告作者选用 VMnet10明显是为了隔离。OpenStack 实验环境下云主机实例、路由器、内部网络都暴露在私有网段里如果桥接到物理局域网等于把内部服务直接晒到真实网络里既不安全也容易被 DHCP 冲突干扰。Host-Only 模式把整条实验链路关在宿主机内部宿主机通过 VMware 虚拟网卡和虚拟机通信这正好匹配报告里「使用 test 用户名登录后打开 Terminal执行 ifconfig 查看网络状态」的路径——因为要满足宿主机浏览器能访问 OpenStack 的 Web 界面VMnet10 必须给 OpenStack 主机分配一个宿主机可达的地址。报告里 ifconfig 显示 192.168.3.40这个地址通常来自实验镜像内置的固定配置或者 VMnet10 网段的 DHCP。我一般会建议在确认 VMnet10 的网段后先用 ping 探一下虚拟机地址是否真的可达避免后续浏览器访问时抓瞎。具体操作如下。# 在宿主机 cmd 里确认 VMnet10 网卡地址 ipconfig # 找到 VMnet10 对应的 IPv4 地址假设是 192.168.3.1 # 然后 ping OpenStack 主机 ping 192.168.3.40 # 如果 ping 不通进入虚拟机终端检查网络状态 ifconfig # 关键看 eth0 是否有 inet 地址以及是否与 VMnet10 同网段这段逻辑要拆开讲ipconfig 是为了确认宿主机侧 VMnet10 的网段ping 是为了验证二层和三层的连通性ifconfig 则是排查看虚拟机侧网卡是否真正拿到了 IP。如果 ping 不通九成原因是虚拟机的网卡没有接到 VMnet10 上——在 VMware 的虚拟机设置里网络适配器必须自定义为 VMnet10而不是默认的 NAT。OpenStack 主机启动后浏览器访问 Dashboard 也有讲究。Horizon 服务在不同发行版里绑定的端口不完全一样常见做法是访问http://192.168.3.40/horizon或http://192.168.3.40:8080具体看镜像里 httpd 的配置。这一步需要明确一个容易混淆的点Dashboard 和 OpenStack API 的端口不同Horizon 走 HTTP/HTTPS而 Keystone 认证服务默认走 5000 和 35357 端口。浏览器访问的是 Web 界面Swift CLI 访问的才是 API 端口两者不能搞混。登录账号也要注意。报告里先提到用 test 用户登录 Linux 主机后提到用 demo 身份凭据登录 Dashboard这两个账号不是一回事。test 是实验镜像的系统用户demo 是 OpenStack 里的 Keystone 用户。OpenStack 的用户体系和 Linux 系统用户完全隔离这一点需要先区分清楚否则后面会出现在 Dashboard 里反复登录失败的情况。3. Dashboard 管理云实例从创建 Inst_demo 到双实例 ping 通环境打通后接下来的重点是把云主机实例创建出来。报告里的操作路径是从 admin 用户注销换 demo 用户登录再创建实例 Inst_demo接着启动 Inst_cirros 和 Inst_fedora最后进入 Console 控制台验证。为什么要从 admin 切到 demo因为 OpenStack 的权限模型讲究最小权限。admin 是管理员视角能看到所有租户的资源demo 则是普通租户用户只能操作自己的资源。实验里让学生切换账号是为了让每个步骤都发生在真实业务用户的权限范围内。这个切换动作在生产环境中很有意义——权限边界划清楚比什么都能操作更重要。创建实例时的参数选择是这一章值得细看的点。虽然报告没有把所有参数都列一遍但结合实验环境通常要选择以下配置参数项推荐值说明镜像cirros / fedora实验镜像体积小启动快规格Flavorm1.tiny / m1.small内存 512MB 起避免宿主机资源耗尽网络private必须选择租户网络否则实例无 IP安全组default保证 ICMP 和 SSH 规则放行密钥对可不填Console 控制台登录不依赖密钥创建完成后报告作者从 Dashboard 进入实例的 Console 控制台去验证网络这一步其实很关键。在 OpenStack 里实例控制台相当于连接到了虚拟机的显示输出你可以直接在浏览器里输入用户名密码登录不需要 SSH 端口暴露。报告里提到的 10.0.0.31 和 10.0.0.121 便是这两个实例从 DHCP 拿到的私有 IP。能否 ping 通直接说明了 Neutron 网络服务是否正确下发。# 进入 Inst_cirros 的 Console 控制台后登录用户通常是 cirros # 默认密码是 cubswin:)但不同镜像有差异 # 登录后执行 ping -c 4 10.0.0.31 ping -c 4 10.0.0.121这里要说明的是 ping 通了代表什么当实例能 ping 通同网段的其他实例说明 Neutron 的 DHCP 服务正常、私有网络连通性好。但注意这并不代表实例能访问外部网络因为外网访问还需要经过路由器。私网内部通只是云内部网络的基本盘。网络服务的理解是报告里另一个信息密度高的地方。报告里有这么一句public 和 private 两个子网private 子网包含两个主机通过 router-demo 路由器连接到 public 网络。并且还在 demo 用户下查看 router-demo 的信息发现它 public 网络接口是 192.168.3.77private 网络接口是 10.0.0.1。这一句信息量很大。在 OpenStack 的 Neutron 架构里router 就是连接外部网络和租户网络的枢纽。它有两个端口一个接在外网这里是 192.168.3.0/24 网段一个接在内网10.0.0.0/24 网段虚拟机发往外网的报文都要经过它做 NAT 转换。10.0.0.1 正是私有网的网关地址虚拟机的默认路由一般指向它。养成一个习惯遇到网络不通时先看路由器的接口状态和地址这一步能定位掉大多数网络问题。Dashboard 本身的界面逻辑也可以提一下。管理员视角下能够看到卷、镜像、网络等全局资源而 demo 用户的界面里看到的是自己租户下的实例和网络。很多新手打开 Dashboard 发现页面和自己组里的同学长得不一样就是因为容器项目和用户权限不同。4. 从认证到对象上传Swift CLI 全命令拆解Swift 对象存储是整个实验的核心模块。这份实验报告把操作聚合成了一条完整的 CLI 链路客户端启动 → 认证 → 访问容器 → 上传对象 → 操作元数据。这一步比前面有意思因为它是完全可以在本地环境模拟的而且命令执行的返回值资料里都有明确标准。Swift CLI 认证的第一步是获取认证信息。在重启客户端、重新登录、网络切换之后先检查环境变量和网络状态再用swift auth或者直接执行swift list触发的认证逻辑获得令牌。实验报告里的做法是先用 test 账户登录 Linux 主机再在终端执行 Swift 命令行工具。# 查看网络状态确认能访问 OpenStack 控制节点 ifconfig # 设置环境变量很多镜像已经把参数写进 admin-openrc / demo-openrc source /opt/stack/devstack/openrc demo demo # 认证并输出认证信息 swift auth这一步的逻辑是Swift CLI 通过 Keystone 完成认证拿到一个临时令牌后续容器的访问都带着这个令牌。OpenStack 的认证流程很像拿一张临时通行证不需要反复输入密码但通行证有过期时间操作超时后要重新认证。这里经常出现的问题是环境变量没生效——因为 openrc 文件里 export 的字段很多遗漏了OS_AUTH_URL或OS_PROJECT_NAMECLI 就会去连一个错误的端点。认证通过后下一步是访问并新建容器。容器相当于对象存储里的文件夹但它不嵌套。# 列出当前账户下所有容器 swift list # 新建容器名字要符合容器命名规范 swift post container-demo # 再次查看容器 swift list容器命名规范值得多说一句。Swift 的容器名和对象名都遵循类似 HTTP URL 路径的规则允许小写字母、数字、下划线、连字符不能有斜杠等特殊字符。实验里一般用学号或者语义化的名字比如后面的 Holidays_学号。这里常踩的坑是容器已存在时重复执行 swift post 会返回成功但实际什么都没做容易产生「我以为重建了容器」的误解。上传对象这一步报告的操作是先在本地新建一个文件再把这个文件作为对象上传到云端容器。# 在本地创建一个测试文件写入一些内容 echo media database and cloud storage test_object.txt # 上传为对象容器名在前本地文件路径在后 swift upload container-demo test_object.txt # 查看容器中的对象列表 swift list container-demo这里值得点透一个概念Swift 上传的对象名称与本地文件名默认相同但对象名本质上是资源标识符和本地路径没有严格绑定关系。如果想在存储端换名执行swift upload container-demo test_object.txt --object-name media_backup/2023/test_object.txt即可这个用法在生产环境很常用用来给对象加逻辑目录。上传过后CLI 会返回文件路径看到类似test_object.txt的输出就说明成功。实验报告在思考题部分专门设计了容器和对象的元数据操作比如给容器Holidays_学号添加元数据year: 2014给对象 Cambridge 添加元数据time: 0203等。在 Swift CLI 里元数据操作的命令模板如下。# 上传 Cambridge 对象本地文件可以是任意内容如一个同名文本 echo cambridge Cambridge swift upload Holidays_2021211013036 Cambridge # 给对象添加 / 修改元数据 swift post Holidays_2021211013036 Cambridge --meta time:0203 # 查看元数据 swift stat Holidays_2021211013036 Cambridge # 给容器添加元数据 swift post Holidays_2021211013036 --meta year:2014 swift stat Holidays_2021211013036 # 删除一条元数据 swift post Holidays_2021211013036 Cambridge --remove-meta time需要解释的是--meta参数的命名习惯。对象和容器的用户自定义元数据在存储系统中会统一加上X-Object-Meta-或X-Container-Meta-前缀CLI 里写--meta time:0203时会把 key 保存为X-Object-Meta-time。删掉一条元数据也不是直接 delete而是用同样的 key 做--remove-meta处理。swift stat命令用于查看容器的元数据、对象内容和对象的元数据输出里还能看到对象的 ETag、Content-Length、Last-Modified 以及多个副本的存储位置信息这对排查上传是否真正持久化很有价值。如果 Swift 容器里对象很多还可以用swift list container-demo --prefix和--delimiter进行前缀过滤从几百个对象里快速定位问题文件。全部命令汇总出来其实不到十个核心记住认证、list、post、upload、stat 五件套整场实验就通了。5. 避坑指南实验全流程最常踩的四个坑这节是本实验报告最接地气的部分。OpenStack 实验环境的报错信息往往很长但没有多少是真正项目相关的错误更多是实验环境自身的脆弱性引起的。下面整理的是按这份流程操作时最容易踩的坑。现象 1宿主机 ping 不通 OpenStack 虚拟机。这种情况是先启动了 OpenStack 主机然后在宿主机里 ping 192.168.3.40完全丢包。 原因通常是 VMware 的 VMnet10 没有和虚拟机关联或者虚拟机的网络适配器仍然选择在 NAT 模式。VMnet10 是 Host-Only 虚拟网络如果虚拟机没有绑定它就等于没插网线。 解决在 VMware 的虚拟机设置里把「网络连接」改为「自定义 - VMnet10」重新启动虚拟机。启动后用ifconfig -a检查是否所有网卡都有地址必要时用dhclient eth0重新请求 IP。现象 2创建实例卡在 Spawning 状态或直接 Error。Dashboard 里创建实例后状态一直显示 Spawning过了几分钟变红。 原因多半是资源不足最常见的是内存或磁盘配额不够。DevStack 单机环境内存本来就紧张如果同时创建两三个实例很容易把宿主机拖垮。 解决先查看宿主机可用资源。执行free -h和df -h确认内存充足。然后删掉规格较大的实例改用m1.tiny规格创建如果换规格还不行看 nova-compute 的日志路径在/var/log/nova/nova-compute.log里面会给出具体的调度失败原因——资源不足时通常会直接写明内存请求不满足。现象 3Swift CLI 认证时报 401 Unauthorized 或连接拒绝。执行swift list时提示HTTPUnauthorized或者直接无法连接到认证服务器。 原因一般是环境变量OS_AUTH_URL指向了错误的地址或者 Keystone 版本号与 CLI 不匹配。DevStack 镜像常见的问题是漏了OS_PROJECT_NAME导致 CLI 不知道该用哪个项目做认证。 解决重新source环境配置文件再用env | grep OS_看全部环境变量。重点检查OS_AUTH_URL里是否带版本号字符如 v3以及是否误加空格。我的习惯是把env | grep OS_的输出和swift auth的分段执行对照排查。现象 4实例能 ping 通内网但访问不了外网。10.0.0.x 网段的实例之间能 ping 通但实例没法和物理网络通信。 原因通常是 Neutron 路由器没有设置网关或外网网段配置不对。报告里提到 router-demo 的 public 接口是 192.168.3.77如果这里没有设置路由器的外部网关数据包到了路由器就被丢弃。 解决进入网络 - 路由器的管理界面检查是否已添加外部网关。网关地址填外部网络的默认路由地址一般是 192.168.3.1。同时确认虚拟机的安全组里放行了 ICMP 和 SSH 规则因为安全组是另一层经常被忽略的拦截点。以上四个问题基本覆盖了报告涉及的每一步可能发生的断裂。希望能成为你做这个实验时的检查手册而不是事后安慰。6. 看懂思考题才算看懂 SwiftIaaS 分层与一致性哈希的完整解答实验报告的课后思考题是检验是否真正理解整个实验知识体系的最佳入口。这部分表面是答题实际上是把实验操作上升为概念验证。这里把每题的关键答案和对照思路拉出来帮你判断自己该在哪个知识点上补课。第一个思考题要求创建Holidays_学号和Sports_学号两个容器并为容器内对象设置不同元数据。这题的本质是验证你是否掌握上传和元数据操作不再展开直接按上一章的 CLI 命令序列执行即可。第二个思考题问 OpenStack 是什么、它和别的开源云计算软件比有什么优势。报告作者从三个对比维度给出答案。一个是和 Windows 系列对比说 OpenStack 便于部署、管理和使用一个是和 UNIX 系列对比说 OpenStack 版本多大多要与硬件相互配套稳定性和可靠性不如 UNIX/Linux另一个是和 Linux 系列对比说 OpenStack 凭借开放性和高性价比获得长足发展。另外单独列出了模块松耦合、组件配置灵活、容易二次开发三个优势点。值得注意的是这个对比写得比较粗糙比如「与 Windows 系列相比」其实并不严谨——Windows 是操作系统OpenStack 是运行在操作系统之上的云管平台两者不在一个抽象层级。拿来应付课程可以但面试时不要这么答。一个更准确的说法是OpenStack 是 IaaS 层开源解决方案与管理程序KVM、Xen、容器技术Docker、Kubernetes都能集成它的价值在于把计算、存储、网络资源以 API 的方式池化并自助发放。第三个思考题问云计算架构和 OpenStack 所属层次。答案是 IaaS、PaaS、SaaS 三层划分OpenStack 属于 IaaS 层。IaaS 提供虚拟机、存储、网络这些基础设施资源PaaS 提供应用运行平台比如数据库服务和容器平台SaaS 直接提供软件服务比如企业邮箱和在线文档。判断一个系统属于哪一层就看用户需要自己管理什么——IaaS 里用户要管操作系统以上的所有层SaaS 里用户只管数据本身。第四个思考题问 Swift 对象存储的逻辑结构和物理结构。逻辑结构很简单就是 Account、Container、Object 三层——账户下有多个容器容器下是多条对象。物理结构则是另一个复杂度量级对象最终落在设备上时经过一致性哈希计算被归入某个分区Partition分区再根据副本策略分布到多台设备上。默认副本数为 3数据会被写入不同节点的三个设备这样单台设备故障不会导致数据丢失。第五个思考题的环Ring原理是整份报告含金量最高的部分。报告里的描述是通过一致性哈希实现存储空间分区把所有哈希值组成一个首尾相接的环将环分割成 N 份虚节点需要存储的对象通过 Hash 映射到哈希环的某个值上从哈希值出发顺时针找遇到的第一个虚节点来负责存储。这个描述是准确的但要真正理解它需要知道它解决了什么问题——服务器数量变化时普通取模哈希会导致几乎所有数据重新分布一致性哈希只影响少量数据的迁移。环上每个设备对应多个虚节点是为了让不同性能的设备出现在环上的概率不均等避免热点。对象名做哈希运算之后落到环上某点顺时针遇到的第一个虚节点就是它的存储位置。这个设计让 Swift 可以做到 Share-nothing 的分布式扩展新增节点时只需要迁移环上少量数据。我最后想多提醒一句一开始我看别人的实验报告总是把目光集中在成功截图和步骤列表上后来实际自己搭建环境时才意识到思考和答案过滤掉的细节才是真正的经验所在。从那以后我每次拿到一份实验报告先跳到最后的思考题把答案通读一遍再回头审视步骤里的参数选择两相对照往往会有意外收获——甚至能发现原报告自己的错误和不确定性。希望这篇拆解也能帮到你。如果你正在做相近的实验或需要一份完整的参考步骤把这份实验报告存下来对照着练会比较省心。做云存储实验动手改参数、大量执行命令和查看真实返回值比看十篇教程都更有效。希望开头的判断——「一份实验报告里藏着整套环境搭建和 Swift 对象的细节」——能在你亲手复现时得到验证。本文还有配套的精品资源点击获取 OpenStack Swift对象存储实战：从环境搭建到Ring原理拆解
简介《媒体数据库与云存储》实验四实验报告是一份围绕OpenStack云计算与Swift对象存储实践撰写的完整实验记录面向高校媒体数据库、云计算及信息通信类专业学生尤其适合需要完成同类实验或想快速掌握云平台操作流程的读者。报告以中国传媒大学课程实验为背景依次展示了VMware中添加VMnet10虚拟网络、启动OpenStack主机、用demo账户登录Dashboard开展租户/用户管理以及创建Inst_demo云主机实例、查看网络拓扑结构等环节随后重点讲解了Swift客户端从认证、容器管理到上传本地对象和操作元数据的完整过程通过test和demo账户的实际操作读者还能直观感受OpenStack的认证机制与多租户权限模型。每个步骤均配有界面截图、命令行输入与返回结果方便读者逐步对照。资源包含一个PDF文件容量约3.66MB结构上从实验目的、环境准备到思考题完整覆盖查找方便。该资料已有84人浏览学习非常适合缺乏实验环境或想系统梳理OpenStack/Swift操作要点的同学文末思考题还比较了OpenStack与Windows、UNIX/Linux系统的差异有助于理解其架构优势与适用场景是一份既能用于个人复习、也可作为实验报告书写思路参考的课程实验材料。1. 一份 OpenStack Swift 实验报告能挖出多少生产级细节先说结论这份《媒体数据库与云存储》实验报告表面是学生作业实际是一个完整的 OpenStack 单机实验环境从零到 Swift 对象存储实战的记录。报告涵盖了 VMnet10 虚拟网络规划、Dashboard 云主机实例创建、Cirros/Fedora 双镜像联通性测试、Swift CLI 认证与容器/对象/元数据操作以及课后思考题里的 IaaS 架构和 Swift 环Ring原理。如果你正在备云计算课设、准备面试里 OpenStack 相关的问题或者单纯想抄一份验证过的实验步骤这份报告里 192.168.3.40、10.0.0.31、router-demo 这些连续可查的 IP 证据链会相当有用。下面我按「环境搭起来 → 实例跑起来 → 对象存进去 → 坑排干净 → 答案读明白」的顺序把这份报告拆开来讲。2. 从镜像恢复 OpenStack 主机VMnet10 与网络地址的那些事云计算实验的第一步永远是网络。报告里写的做法是在 VMware 中添加 VMnet10 虚拟网络然后从已有镜像生成 OpenStack 主机。这一步看着简单实际决定后面所有操作能不能联通。VMware 有三种常见的网络模式选错一个后面 OpenStack 的 Dashboard 就登不进去。它们的区别如下网络模式虚拟机与外网关系虚拟机间通信宿主机访问虚拟机典型用途NAT共享宿主机 IP 访问外网支持需要端口映射虚拟机要上外网装软件Bridged与宿主机在同一广播域支持直接同网段访问虚拟机需接入局域网Host-OnlyVMnet10不提供外网访问支持支持靠虚拟网卡纯内网实验环境报告作者选用 VMnet10明显是为了隔离。OpenStack 实验环境下云主机实例、路由器、内部网络都暴露在私有网段里如果桥接到物理局域网等于把内部服务直接晒到真实网络里既不安全也容易被 DHCP 冲突干扰。Host-Only 模式把整条实验链路关在宿主机内部宿主机通过 VMware 虚拟网卡和虚拟机通信这正好匹配报告里「使用 test 用户名登录后打开 Terminal执行 ifconfig 查看网络状态」的路径——因为要满足宿主机浏览器能访问 OpenStack 的 Web 界面VMnet10 必须给 OpenStack 主机分配一个宿主机可达的地址。报告里 ifconfig 显示 192.168.3.40这个地址通常来自实验镜像内置的固定配置或者 VMnet10 网段的 DHCP。我一般会建议在确认 VMnet10 的网段后先用 ping 探一下虚拟机地址是否真的可达避免后续浏览器访问时抓瞎。具体操作如下。# 在宿主机 cmd 里确认 VMnet10 网卡地址 ipconfig # 找到 VMnet10 对应的 IPv4 地址假设是 192.168.3.1 # 然后 ping OpenStack 主机 ping 192.168.3.40 # 如果 ping 不通进入虚拟机终端检查网络状态 ifconfig # 关键看 eth0 是否有 inet 地址以及是否与 VMnet10 同网段这段逻辑要拆开讲ipconfig 是为了确认宿主机侧 VMnet10 的网段ping 是为了验证二层和三层的连通性ifconfig 则是排查看虚拟机侧网卡是否真正拿到了 IP。如果 ping 不通九成原因是虚拟机的网卡没有接到 VMnet10 上——在 VMware 的虚拟机设置里网络适配器必须自定义为 VMnet10而不是默认的 NAT。OpenStack 主机启动后浏览器访问 Dashboard 也有讲究。Horizon 服务在不同发行版里绑定的端口不完全一样常见做法是访问http://192.168.3.40/horizon或http://192.168.3.40:8080具体看镜像里 httpd 的配置。这一步需要明确一个容易混淆的点Dashboard 和 OpenStack API 的端口不同Horizon 走 HTTP/HTTPS而 Keystone 认证服务默认走 5000 和 35357 端口。浏览器访问的是 Web 界面Swift CLI 访问的才是 API 端口两者不能搞混。登录账号也要注意。报告里先提到用 test 用户登录 Linux 主机后提到用 demo 身份凭据登录 Dashboard这两个账号不是一回事。test 是实验镜像的系统用户demo 是 OpenStack 里的 Keystone 用户。OpenStack 的用户体系和 Linux 系统用户完全隔离这一点需要先区分清楚否则后面会出现在 Dashboard 里反复登录失败的情况。3. Dashboard 管理云实例从创建 Inst_demo 到双实例 ping 通环境打通后接下来的重点是把云主机实例创建出来。报告里的操作路径是从 admin 用户注销换 demo 用户登录再创建实例 Inst_demo接着启动 Inst_cirros 和 Inst_fedora最后进入 Console 控制台验证。为什么要从 admin 切到 demo因为 OpenStack 的权限模型讲究最小权限。admin 是管理员视角能看到所有租户的资源demo 则是普通租户用户只能操作自己的资源。实验里让学生切换账号是为了让每个步骤都发生在真实业务用户的权限范围内。这个切换动作在生产环境中很有意义——权限边界划清楚比什么都能操作更重要。创建实例时的参数选择是这一章值得细看的点。虽然报告没有把所有参数都列一遍但结合实验环境通常要选择以下配置参数项推荐值说明镜像cirros / fedora实验镜像体积小启动快规格Flavorm1.tiny / m1.small内存 512MB 起避免宿主机资源耗尽网络private必须选择租户网络否则实例无 IP安全组default保证 ICMP 和 SSH 规则放行密钥对可不填Console 控制台登录不依赖密钥创建完成后报告作者从 Dashboard 进入实例的 Console 控制台去验证网络这一步其实很关键。在 OpenStack 里实例控制台相当于连接到了虚拟机的显示输出你可以直接在浏览器里输入用户名密码登录不需要 SSH 端口暴露。报告里提到的 10.0.0.31 和 10.0.0.121 便是这两个实例从 DHCP 拿到的私有 IP。能否 ping 通直接说明了 Neutron 网络服务是否正确下发。# 进入 Inst_cirros 的 Console 控制台后登录用户通常是 cirros # 默认密码是 cubswin:)但不同镜像有差异 # 登录后执行 ping -c 4 10.0.0.31 ping -c 4 10.0.0.121这里要说明的是 ping 通了代表什么当实例能 ping 通同网段的其他实例说明 Neutron 的 DHCP 服务正常、私有网络连通性好。但注意这并不代表实例能访问外部网络因为外网访问还需要经过路由器。私网内部通只是云内部网络的基本盘。网络服务的理解是报告里另一个信息密度高的地方。报告里有这么一句public 和 private 两个子网private 子网包含两个主机通过 router-demo 路由器连接到 public 网络。并且还在 demo 用户下查看 router-demo 的信息发现它 public 网络接口是 192.168.3.77private 网络接口是 10.0.0.1。这一句信息量很大。在 OpenStack 的 Neutron 架构里router 就是连接外部网络和租户网络的枢纽。它有两个端口一个接在外网这里是 192.168.3.0/24 网段一个接在内网10.0.0.0/24 网段虚拟机发往外网的报文都要经过它做 NAT 转换。10.0.0.1 正是私有网的网关地址虚拟机的默认路由一般指向它。养成一个习惯遇到网络不通时先看路由器的接口状态和地址这一步能定位掉大多数网络问题。Dashboard 本身的界面逻辑也可以提一下。管理员视角下能够看到卷、镜像、网络等全局资源而 demo 用户的界面里看到的是自己租户下的实例和网络。很多新手打开 Dashboard 发现页面和自己组里的同学长得不一样就是因为容器项目和用户权限不同。4. 从认证到对象上传Swift CLI 全命令拆解Swift 对象存储是整个实验的核心模块。这份实验报告把操作聚合成了一条完整的 CLI 链路客户端启动 → 认证 → 访问容器 → 上传对象 → 操作元数据。这一步比前面有意思因为它是完全可以在本地环境模拟的而且命令执行的返回值资料里都有明确标准。Swift CLI 认证的第一步是获取认证信息。在重启客户端、重新登录、网络切换之后先检查环境变量和网络状态再用swift auth或者直接执行swift list触发的认证逻辑获得令牌。实验报告里的做法是先用 test 账户登录 Linux 主机再在终端执行 Swift 命令行工具。# 查看网络状态确认能访问 OpenStack 控制节点 ifconfig # 设置环境变量很多镜像已经把参数写进 admin-openrc / demo-openrc source /opt/stack/devstack/openrc demo demo # 认证并输出认证信息 swift auth这一步的逻辑是Swift CLI 通过 Keystone 完成认证拿到一个临时令牌后续容器的访问都带着这个令牌。OpenStack 的认证流程很像拿一张临时通行证不需要反复输入密码但通行证有过期时间操作超时后要重新认证。这里经常出现的问题是环境变量没生效——因为 openrc 文件里 export 的字段很多遗漏了OS_AUTH_URL或OS_PROJECT_NAMECLI 就会去连一个错误的端点。认证通过后下一步是访问并新建容器。容器相当于对象存储里的文件夹但它不嵌套。# 列出当前账户下所有容器 swift list # 新建容器名字要符合容器命名规范 swift post container-demo # 再次查看容器 swift list容器命名规范值得多说一句。Swift 的容器名和对象名都遵循类似 HTTP URL 路径的规则允许小写字母、数字、下划线、连字符不能有斜杠等特殊字符。实验里一般用学号或者语义化的名字比如后面的 Holidays_学号。这里常踩的坑是容器已存在时重复执行 swift post 会返回成功但实际什么都没做容易产生「我以为重建了容器」的误解。上传对象这一步报告的操作是先在本地新建一个文件再把这个文件作为对象上传到云端容器。# 在本地创建一个测试文件写入一些内容 echo media database and cloud storage test_object.txt # 上传为对象容器名在前本地文件路径在后 swift upload container-demo test_object.txt # 查看容器中的对象列表 swift list container-demo这里值得点透一个概念Swift 上传的对象名称与本地文件名默认相同但对象名本质上是资源标识符和本地路径没有严格绑定关系。如果想在存储端换名执行swift upload container-demo test_object.txt --object-name media_backup/2023/test_object.txt即可这个用法在生产环境很常用用来给对象加逻辑目录。上传过后CLI 会返回文件路径看到类似test_object.txt的输出就说明成功。实验报告在思考题部分专门设计了容器和对象的元数据操作比如给容器Holidays_学号添加元数据year: 2014给对象 Cambridge 添加元数据time: 0203等。在 Swift CLI 里元数据操作的命令模板如下。# 上传 Cambridge 对象本地文件可以是任意内容如一个同名文本 echo cambridge Cambridge swift upload Holidays_2021211013036 Cambridge # 给对象添加 / 修改元数据 swift post Holidays_2021211013036 Cambridge --meta time:0203 # 查看元数据 swift stat Holidays_2021211013036 Cambridge # 给容器添加元数据 swift post Holidays_2021211013036 --meta year:2014 swift stat Holidays_2021211013036 # 删除一条元数据 swift post Holidays_2021211013036 Cambridge --remove-meta time需要解释的是--meta参数的命名习惯。对象和容器的用户自定义元数据在存储系统中会统一加上X-Object-Meta-或X-Container-Meta-前缀CLI 里写--meta time:0203时会把 key 保存为X-Object-Meta-time。删掉一条元数据也不是直接 delete而是用同样的 key 做--remove-meta处理。swift stat命令用于查看容器的元数据、对象内容和对象的元数据输出里还能看到对象的 ETag、Content-Length、Last-Modified 以及多个副本的存储位置信息这对排查上传是否真正持久化很有价值。如果 Swift 容器里对象很多还可以用swift list container-demo --prefix和--delimiter进行前缀过滤从几百个对象里快速定位问题文件。全部命令汇总出来其实不到十个核心记住认证、list、post、upload、stat 五件套整场实验就通了。5. 避坑指南实验全流程最常踩的四个坑这节是本实验报告最接地气的部分。OpenStack 实验环境的报错信息往往很长但没有多少是真正项目相关的错误更多是实验环境自身的脆弱性引起的。下面整理的是按这份流程操作时最容易踩的坑。现象 1宿主机 ping 不通 OpenStack 虚拟机。这种情况是先启动了 OpenStack 主机然后在宿主机里 ping 192.168.3.40完全丢包。 原因通常是 VMware 的 VMnet10 没有和虚拟机关联或者虚拟机的网络适配器仍然选择在 NAT 模式。VMnet10 是 Host-Only 虚拟网络如果虚拟机没有绑定它就等于没插网线。 解决在 VMware 的虚拟机设置里把「网络连接」改为「自定义 - VMnet10」重新启动虚拟机。启动后用ifconfig -a检查是否所有网卡都有地址必要时用dhclient eth0重新请求 IP。现象 2创建实例卡在 Spawning 状态或直接 Error。Dashboard 里创建实例后状态一直显示 Spawning过了几分钟变红。 原因多半是资源不足最常见的是内存或磁盘配额不够。DevStack 单机环境内存本来就紧张如果同时创建两三个实例很容易把宿主机拖垮。 解决先查看宿主机可用资源。执行free -h和df -h确认内存充足。然后删掉规格较大的实例改用m1.tiny规格创建如果换规格还不行看 nova-compute 的日志路径在/var/log/nova/nova-compute.log里面会给出具体的调度失败原因——资源不足时通常会直接写明内存请求不满足。现象 3Swift CLI 认证时报 401 Unauthorized 或连接拒绝。执行swift list时提示HTTPUnauthorized或者直接无法连接到认证服务器。 原因一般是环境变量OS_AUTH_URL指向了错误的地址或者 Keystone 版本号与 CLI 不匹配。DevStack 镜像常见的问题是漏了OS_PROJECT_NAME导致 CLI 不知道该用哪个项目做认证。 解决重新source环境配置文件再用env | grep OS_看全部环境变量。重点检查OS_AUTH_URL里是否带版本号字符如 v3以及是否误加空格。我的习惯是把env | grep OS_的输出和swift auth的分段执行对照排查。现象 4实例能 ping 通内网但访问不了外网。10.0.0.x 网段的实例之间能 ping 通但实例没法和物理网络通信。 原因通常是 Neutron 路由器没有设置网关或外网网段配置不对。报告里提到 router-demo 的 public 接口是 192.168.3.77如果这里没有设置路由器的外部网关数据包到了路由器就被丢弃。 解决进入网络 - 路由器的管理界面检查是否已添加外部网关。网关地址填外部网络的默认路由地址一般是 192.168.3.1。同时确认虚拟机的安全组里放行了 ICMP 和 SSH 规则因为安全组是另一层经常被忽略的拦截点。以上四个问题基本覆盖了报告涉及的每一步可能发生的断裂。希望能成为你做这个实验时的检查手册而不是事后安慰。6. 看懂思考题才算看懂 SwiftIaaS 分层与一致性哈希的完整解答实验报告的课后思考题是检验是否真正理解整个实验知识体系的最佳入口。这部分表面是答题实际上是把实验操作上升为概念验证。这里把每题的关键答案和对照思路拉出来帮你判断自己该在哪个知识点上补课。第一个思考题要求创建Holidays_学号和Sports_学号两个容器并为容器内对象设置不同元数据。这题的本质是验证你是否掌握上传和元数据操作不再展开直接按上一章的 CLI 命令序列执行即可。第二个思考题问 OpenStack 是什么、它和别的开源云计算软件比有什么优势。报告作者从三个对比维度给出答案。一个是和 Windows 系列对比说 OpenStack 便于部署、管理和使用一个是和 UNIX 系列对比说 OpenStack 版本多大多要与硬件相互配套稳定性和可靠性不如 UNIX/Linux另一个是和 Linux 系列对比说 OpenStack 凭借开放性和高性价比获得长足发展。另外单独列出了模块松耦合、组件配置灵活、容易二次开发三个优势点。值得注意的是这个对比写得比较粗糙比如「与 Windows 系列相比」其实并不严谨——Windows 是操作系统OpenStack 是运行在操作系统之上的云管平台两者不在一个抽象层级。拿来应付课程可以但面试时不要这么答。一个更准确的说法是OpenStack 是 IaaS 层开源解决方案与管理程序KVM、Xen、容器技术Docker、Kubernetes都能集成它的价值在于把计算、存储、网络资源以 API 的方式池化并自助发放。第三个思考题问云计算架构和 OpenStack 所属层次。答案是 IaaS、PaaS、SaaS 三层划分OpenStack 属于 IaaS 层。IaaS 提供虚拟机、存储、网络这些基础设施资源PaaS 提供应用运行平台比如数据库服务和容器平台SaaS 直接提供软件服务比如企业邮箱和在线文档。判断一个系统属于哪一层就看用户需要自己管理什么——IaaS 里用户要管操作系统以上的所有层SaaS 里用户只管数据本身。第四个思考题问 Swift 对象存储的逻辑结构和物理结构。逻辑结构很简单就是 Account、Container、Object 三层——账户下有多个容器容器下是多条对象。物理结构则是另一个复杂度量级对象最终落在设备上时经过一致性哈希计算被归入某个分区Partition分区再根据副本策略分布到多台设备上。默认副本数为 3数据会被写入不同节点的三个设备这样单台设备故障不会导致数据丢失。第五个思考题的环Ring原理是整份报告含金量最高的部分。报告里的描述是通过一致性哈希实现存储空间分区把所有哈希值组成一个首尾相接的环将环分割成 N 份虚节点需要存储的对象通过 Hash 映射到哈希环的某个值上从哈希值出发顺时针找遇到的第一个虚节点来负责存储。这个描述是准确的但要真正理解它需要知道它解决了什么问题——服务器数量变化时普通取模哈希会导致几乎所有数据重新分布一致性哈希只影响少量数据的迁移。环上每个设备对应多个虚节点是为了让不同性能的设备出现在环上的概率不均等避免热点。对象名做哈希运算之后落到环上某点顺时针遇到的第一个虚节点就是它的存储位置。这个设计让 Swift 可以做到 Share-nothing 的分布式扩展新增节点时只需要迁移环上少量数据。我最后想多提醒一句一开始我看别人的实验报告总是把目光集中在成功截图和步骤列表上后来实际自己搭建环境时才意识到思考和答案过滤掉的细节才是真正的经验所在。从那以后我每次拿到一份实验报告先跳到最后的思考题把答案通读一遍再回头审视步骤里的参数选择两相对照往往会有意外收获——甚至能发现原报告自己的错误和不确定性。希望这篇拆解也能帮到你。如果你正在做相近的实验或需要一份完整的参考步骤把这份实验报告存下来对照着练会比较省心。做云存储实验动手改参数、大量执行命令和查看真实返回值比看十篇教程都更有效。希望开头的判断——「一份实验报告里藏着整套环境搭建和 Swift 对象的细节」——能在你亲手复现时得到验证。本文还有配套的精品资源点击获取