将 instance 连接到 vlan100- 每天5分钟玩转 OpenStack(95)

上一节我们创建了 vlan100,今天将部署两个 instance 到 vlan 并验证其连通性。

同时我们也将讨论底层网络结构的变化。

launch 新的 instance “cirros-vm1”,网络选择 vlan100。

cirros-vm1 分配到的 IP 为 172.16.100.3。

cirros-vm1 被 schedule 到控制节点,对应的 tap 设备为 tapc1875c7f-cb,并且连接到 bridge。

当前 vlan100 的结构如下。

继续用同样的方式 launch instance cirros-vm2,分配到的 IP 为 172.16.100.104。

cirros-vm2 被 schedule 到计算节点,对应的 tap 设备为 tapac94e0e8-2b,并且连接到 bridge。

因为计算节点上没有 hdcp 服务,所以没有相应的 tap 设备。 另外,bridge 的名称与控制节点上一致,都是 brq3fcfdb98-9d,表明是同一个 network。

当前 vlan100 的结构如下:

cirros-vm1(172.16.100.3) 与 cirros-vm2(172.16.100.4) 位于不同节点,通过 vlan100 相连,下面执行 PING 验证连通性。 在 cirros-vm1 控制台中执行 ping 172.16.100.4。

如我们预料,ping 成功。

下一节将继续创建 vlan101 并观察新的网络结构变化。

时间: 2024-12-14 11:19:56

将 instance 连接到 vlan100- 每天5分钟玩转 OpenStack(95)的相关文章

将 instance 连接到 first_local_net - 每天5分钟玩转 OpenStack(82)

上一节 first_local_net 已经就绪,下面创建 instance 并将其连接到该网络. 将 instance 连接到 first_local_net launch 一个 instance,在“Networking”标签页面选择 first_local_net 网络. instance 部署成功,分配的 IP 地址为 172.16.1.3 底层网络发生了什么变化? 对于 instance “cirros-vm1”,Neutron 会在 subnet 中创建一个 port,分配 IP 和

将 instance 连接到 flat_net - 每天5分钟玩转 OpenStack(88)

上一节我们创建了 "flat_net",本节将在此网络中部署 instance 并验证连通性. launch 新的 instance “cirros-vm1”,选择网络 falt_net. cirros-vm1 分配到的 IP 为 172.16.1.103. cirros-vm1 被 schedule 到控制节点,对应的 tap 设备为 tapc1875c7f-cb,并且已经连接到 bridge. 当前 flat_net 的结构如下: 继续用同样的方式 launch instance

将 instance 连接到 second_local_net - 每天5分钟玩转 OpenStack(85)

今天是 local network 的最后一个小节,我们将验证两个local network 的连通性. launch 新的 instance “cirros-vm3”,网络选择 second_local_net. cirros-vm3 分配到的 IP 为 172.16.1.102. cirros-vm3 被 schedule 到控制节点,对应的 tap 设备为 tap5395d19b-ed. 控制台显示 cirros-vm3 已经成功从 DHCP 拿到 IP 地址 172.16.1.102.

创建第一个 vlan network "vlan100" - 每天5分钟玩转 OpenStack(94)

上一节我们在 ML2 配置中 enable 了 vlan network,今天将创建 vlan100 并讨论底层网络变化. 打开菜单 Admin -> Networks,点击 "Create Network" 按钮. 显示创建页面. Provider Network Type 选择 "VLAN". Physical Network 填写 "default",必须与 ml2_conf.ini network_vlan_ranges 保持一致.

再部署一个 instance 和 Local Network - 每天5分钟玩转 OpenStack(131)

上一节部署了 cirros-vm1 到 first_local_net,今天我们将再部署 cirros-vm2 到同一网络,并创建 second_local_net. 连接第二个 instance 到 first_local_net 以同样的方式 launch instance "cirros-vm2",分配的 IP 为 172.16.1.4. cirros-vm2 也被 schedule 到控制节点,ovs-vsctl show 的输出如下: cirros-vm2 对于的 tap 设

Resize Instance 操作详解 - 每天5分钟玩转 OpenStack(41)

Resize 的作用是调整 instance 的 vCPU.内存和磁盘资源. Instance 需要多少资源是定义在 flavor 中的,resize 操作是通过为 instance 选择新的 flavor 来调整资源的分配. 有了前面对 Migrate 的分析,再来看 Resize 的实现就非常简单了. 因为 instance 需要分配的资源发生了变化,在 resize 之前需要借助 nova-scheduler 重新为 instance 选择一个合适的计算节点,如果选择的节点与当前节点不是同

Migrate Instance 操作详解 - 每天5分钟玩转 OpenStack(40)

Migrate 操作的作用是将 instance 从当前的计算节点迁移到其他节点上. Migrate 不要求源和目标节点必须共享存储,当然共享存储也是可以的. Migrate 前必须满足一个条件:计算节点间需要配置 nova 用户无密码访问. 下面是 Migrate instance 的流程图 向 nova-api 发送请求 nova-api 发送消息 nova-scheduler 执行调度 nova-scheduler 发送消息 nova-compute 执行操作 下面我们详细讨论每一个步骤.

Unshelve Instance 操作详解 - 每天5分钟玩转 OpenStack(39)

上一节我们 shelve instance 到 Glance,本节讨论如何通过 unshelve 操作恢复该 instance. 因为 Glance 中保存了 instance 的 image,unshelve 的过程其实就是通过该 image launch 一个新的 instance,nova-scheduler 也会调度合适的计算节点来创建该 instance. instance unshelve 后可能运行在与 shelve 之前不同的计算节点上,但 instance 的其他属性(比如 f

Shelve Instance 操作详解 - 每天5分钟玩转 OpenStack(38)

Instance 被 Suspend 后虽然处于 Shut Down 状态,但 Hypervisor 依然在宿主机上为其预留了资源,以便在以后能够成功 Resume. 如果希望释放这些预留资源,可以使用 Shelve 操作. Shelve 会将 instance 作为 image 保存到 Glance 中,然后在宿主机上删除该 instance. 下面是 shelve instance 的流程图 向 nova-api 发送请求 nova-api 发送消息 nova-compute 执行操作 下面

Snapshot Instance 操作详解 - 每天5分钟玩转 OpenStack(36)

本节我们通过日志详细讨论 instance 的 snapshot 操作. 有时候操作系统损坏得很严重,通过 Rescue 操作无法修复,那么我们就得考虑通过备份恢复了.当然前提是我们之前对instance做过备份. Nova 备份的操作叫 Snapshot,其工作原理是对 instance 的镜像文件(系统盘)进行全量备份,生成一个类型为 snapshot 的 image,然后将其保存到 Glance 上. 从备份恢复的操作叫 Rebuild,将在下一节重点讨论. 下面是 snapshot in