实践 Neutron 前的两个准备工作 - 每天5分钟玩转 OpenStack(78)

上一节配置了 linux-bridge mechanism driver,本节再做两个准备工作:

1. 检视初始的网络状态。
2. 了解 linux bridge 环境中的各种网络设备。

初始网络状态

我们首先考察实验环境最初始的网络状态。随着学习的深入,我们会对网络不断进行新的配置,大家也将看到网络一步一步发生的变化。

在我们的实验环境中,当前节点上只存在物理网卡设备 ethX,还没有 bridge 和 tap,状态如下:

控制节点

计算节点

了解 linux bridge 环境中的各种网络设备

在配置 linux bridge driver 之前先了解几种网络设备,后面会经常用到。

在 linux bridge 环境中,一个数据包从 instance 发送到物理网卡会经过下面几个类型的设备:

  1. tap interface
    命名为 tapN (N 为 0, 1, 2, 3......)。
  2. linux bridge
    命名为 brqXXXX。
  3. vlan interface
    命名为 ethX.Y(X 为 interface 的序号,Y 为 vlan id)。
  4. vxlan interface
    命名为 vxlan-Z(z 是 VNI)。
  5. 物理 interface
    命名为 ethX(X 为 interface 的序号)。

vlan interface 会在 vlan 网络中使用;vxlan interface 会在 vxlan 网络中使用。

linux-bridge 支持 local, flat, vlan 和 vxlan 四种 network type,目前不支持 gre。

有了上面的这些准备,我们可以开始深入学习 linux bridge 如何实现每种 network type 了。
下一节将首先学习最简单的 local network。

 

时间: 2024-09-21 19:43:12

实践 Neutron 前的两个准备工作 - 每天5分钟玩转 OpenStack(78)的相关文章

Neutron 功能概述 - 每天5分钟玩转 OpenStack(65)

从今天开始,我们将学习 OpenStack 的 Networking Service,Neutron.Neutron 的难度会比前面所有模块都大一些,内容也多一些.为了帮助大家更好的掌握 Neutorn,CloudMan 也会分析地更详细一些. Neutron 概述 传统的网络管理方式很大程度上依赖于管理员手工配置和维护各种网络硬件设备:而云环境下的网络已经变得非常复杂,特别是在多租户场景里,用户随时都可能需要创建.修改和删除网络,网络的连通性和隔离已经不太可能通过手工配置来保证了. 如何快速响

理解 Neutron Server 分层模型 - 每天5分钟玩转 OpenStack(69)

本节开始讨论 Neutron 的各个服务组件,首先学习 Neutron Server . 上图是 Neutron Server 的分层结构,至上而下依次为: Core API对外提供管理 network, subnet 和 port 的 RESTful API. Extension API对外提供管理 router, load balance, firewall 等资源 的 RESTful API. Commnon Service认证和校验 API 请求. Neutron CoreNeutron

两张图总结 Neutron 架构 - 每天5分钟玩转 OpenStack(74)

前面我们详细讨论了 Neutron 架构,包括 Neutron Server,Core 和 Service Agent.现在用两张图做个总结.先看第一张: 与 OpenStack 其他服务一样,Neutron 采用的是分布式架构,包括 Neutorn Server.各种 plugin/agent.database 和 message queue. Neutron server 接收 api 请求. plugin/agent 实现请求. database 保存 neutron 网络状态. mess

实践 Neutron FWaaS - 每天5分钟玩转 OpenStack(118)

前面我们学习了 FWaaS 的理论知识,今天将通过实验来学习 FWaaS. 在我们的实验环境中,有两个 instance: cirros-vm1(172.16.100.3) 和 cirros-vm2(172.16.101.3). cirros-vm1 和 cirros-vm2 分别位于网络 vlan100 和 vlan101. vlan100 和 vlan101 之间由虚拟路由器 test_router 连接. 网络拓扑如下: 在 test_router 没有应用任何 FWaaS 的情况下,ci

Neutron 默认安全组规则 - 每天5分钟玩转 OpenStack(115)

Neutron 为 instance 提供了两种管理网络安全的方法: 安全组(Security Group)和虚拟防火墙. 安全组的原理是通过 iptables 对 instance 所在计算节点的网络流量进行过滤. 虚拟防火墙则由 Neutron Firewall as a Service(FWaaS)高级服务提供. 其底层也是使用 iptables,在 Neutron Router 上对网络包进行过滤. 这两种安全方案我们都会讨论,本章先重点学习安全组. 默认安全组 每个 Project(租

实践 config drive - 每天5分钟玩转 OpenStack(170)

如果 instance 无法通过 metadata service 获取 metadata(无 DHCP 或者 nova-api-metadata 服务),instance 还可以通过 config drive 获得 metadata.   config drive 是一个特殊的文件系统,OpenStack 会将 metadata 写到 config drive,并在 instance 启动时挂载给 instance.如过 instance 安装了 cloud-init,config drive

为 Neutron 准备物理基础设施(I) - 每天5分钟玩转 OpenStack(75)

前面讨论了 Neutron 的架构和基础知识,接下来就要通过实验深入学习和实践了. 第一步就是准备实验用的物理环境,考虑如下几个问题: 需要几个节点? 如何分配节点的角色? 节点上部署哪些服务? 配几个网卡? 物理网络如何连接? 1 控制节点 + 1 计算节点 的部署方案 我们的目的是通过实验学习 Neutron 的各种特性. 为了达到这个目的,实验环境应尽量贴近典型的部署方案:但同时,由于是个人学习使用,受物理条件的限制需要尽量利用有限的资源,所以我们采用下面的部署方案: Q:需要几个节点?

Neutron 架构 - 每天5分钟玩转 OpenStack(67)

前面我们讨论了 Neutron 的基本概念,今天我们开始分析 Neutron 的架构. Neutron 架构 与 OpenStack 的其他服务的设计思路一样,Neutron 也是采用分布式架构,由多个组件(子服务)共同对外提供网络服务. Neutron 由如下组件构成: Neutron Server对外提供 OpenStack 网络 API,接收请求,并调用 Plugin 处理请求. Plugin处理 Neutron Server 发来的请求,维护 OpenStack 逻辑网络的状态, 并调用

FWaaS 实践: 允许 ssh - 每天5分钟玩转 OpenStack(119)

上一节应用了无规则的虚拟防火墙,不允许任何流量通过. 今天我们会在防火墙中添加一条规则,允许 ssh.最后我们会对安全组和 FWaaS 作个比较. 下面我们添加一条 firewall rule:允许 ssh. 在 Firewall Rules 标签页面点击 "Add Rule" 按钮. 将新 rule 命名为 "allow ssh", Protocal 选择 "TCP", Action 为 "ALLOW", Destinati