OpenStack实践系列⑦深入理解neutron和虚拟机

时间:2023-03-09 01:33:28
OpenStack实践系列⑦深入理解neutron和虚拟机

OpenStack实践系列⑦深入理解neutron和虚拟机

五、深入理解Neutron

OpenStack实践系列⑦深入理解neutron和虚拟机

5.1 虚拟机网卡和网桥

[root@node1 ~]# ifconfig
brq65c11cc3-8e: flags=<UP,BROADCAST,RUNNING,MULTICAST> mtu
inet 192.168.3.199 netmask 255.255.255.0 broadcast 192.168.3.255
ether :::3b:dc:7e txqueuelen (Ethernet)
RX packets bytes (168.6 MiB)
RX errors dropped overruns frame
TX packets bytes (44.7 MiB)
TX errors dropped overruns carrier collisions eth0: flags=<UP,BROADCAST,RUNNING,MULTICAST> mtu
ether :::3b:dc:7e txqueuelen (Ethernet)
RX packets bytes (1.0 GiB)
RX errors dropped overruns frame
TX packets bytes (51.5 MiB)
TX errors dropped overruns carrier collisions lo: flags=<UP,LOOPBACK,RUNNING> mtu
inet 127.0.0.1 netmask 255.0.0.0
inet6 :: prefixlen scopeid 0x10<host>
loop txqueuelen (Local Loopback)
RX packets bytes (201.1 MiB)
RX errors dropped overruns frame
TX packets bytes (201.1 MiB)
TX errors dropped overruns carrier collisions tap436a0452-af: flags=<UP,BROADCAST,RUNNING,MULTICAST> mtu
ether 4a:a6:af:6e:: txqueuelen (Ethernet)
RX packets bytes (1.5 MiB)
RX errors dropped overruns frame
TX packets bytes (158.1 MiB)
TX errors dropped overruns carrier collisions [root@node1 ~]# brctl show
bridge name bridge id STP enabled interfaces
brq65c11cc3-8e .0050563bdc7e no eth0
tap436a0452-af
brq65c11cc3-8e(网桥):可以理解为一个小交换机,网桥上的设备都和eth0能通(数据链路层),其中tap436a0452-af作为虚拟机的网卡,从而实现通信

5.2 不同场景网络类型和OpenStack网络分层

5.2.1 Openstack网络分类

OpenStack实践系列⑦深入理解neutron和虚拟机

5.2.2Openstack网络分层

首先网络分层肯定是基于OSI七层模型的,在这里就不在赘述,只对Openstack的网络进行分层讲解

网络:在实际的物理环境下,我们使用交换机或者集线器把多个计算机连接起来形成了网络,在Neutron的世界里,网络也是将多个不同的云主机连接起来。
子网:在实际的物理环境下,在一个网络中,我们可以将网络划分成多个逻辑子网,在Neutron的世界里,子网也是路属于网络下的
端口:在实际的物理环境下,每个字子网或者每个网络,都有很多的端口,比如交换机端口来供计算机链接,在Neutron的世界里端口也是隶属于子网下,云主机的网卡会对应到一个端口上。
路由器:在实际的网络环境下,不同网络或者不同逻辑子网之间如果需要进行通信,需要通过路由器进行路由,在Neutron的实际里路由也是这个作用,用来连接不同的网络或者子网。
5.3 五种neutron常见的模型

单一平面网络(也叫大二层网络,最初的 nova-network 网络模型)
单一平面网络的缺点:
a.存在单一网络瓶颈,缺乏可伸缩性。
b.缺乏合适的多租户隔离。
c.容易发生广播风暴,而且不能使用keepalived(vrrp组播)

OpenStack实践系列⑦深入理解neutron和虚拟机

多平面网络

OpenStack实践系列⑦深入理解neutron和虚拟机

混合平面私有网络

OpenStack实践系列⑦深入理解neutron和虚拟机

通过私有网络实现运营商路由功能

OpenStack实践系列⑦深入理解neutron和虚拟机

通过私有网络实现每个租户创建自己专属的网络区段

OpenStack实践系列⑦深入理解neutron和虚拟机

5.4 图解Neutron服务的几大组件

OpenStack实践系列⑦深入理解neutron和虚拟机

ML2(The Modular Layer2):提供一个新的插件ML2,这个插件可以作为一个框架同时支持不同的2层网络,类似于中间协调在作用,通过ml2
调用linuxbridge、openvswitch和其他商业的插件,保证了可以同时使用linuxbridge、openvswitch和其他商业的插件。
DHCP-Agent:为虚拟机分配IP地址,在创建虚拟机之前,创建了一个IP地址池,就是为了给虚拟机分配IP地址的。具体如下:

interface_driver = neutron.agent.linux.interface.BridgeInterfaceDriver

Dhcp-agent需要配置与plugin对应的interface_driver

dhcp_driver = neutron.agent.linux.dhcp.Dnsmasq

当启动一个实例时,分配和配置(ip)的程序包含一个在dnsmasq config中储存ip地址的进程,接着启动或重载dnsmasq。通常,OpenStack在每个网络中只有一个neutron-dhcp-agent负责spawn一个dnsmasq,所以一个庞大的网络(包含所有子网)中只会有一个dnsmasq提供服务。理论上,并且根据实用的实验室测试,dnsmasq应该能每秒处理1000个DHCP请求
enable_isolated_metadata = true 启用独立的metadata,后续会有说明

L3-agent:名字为neutron-l3-agent,为客户机访问外部网络提供3层转发服务。也部署在网络节点上。
LBaas:负载均衡及服务。后续会有说明

六、虚拟机知多少
虚拟机对于宿主机来说,知识一个进程,通过libvirt调用kvm进行管理虚拟机,当然也可以使用virsh工具来管理虚拟机

查看所虚拟机的真实内容

切换到虚拟机默认的存放路径

[root@node2 ~]# cd /var/lib/nova/instances/
[root@node2 instances]# ls
b6ba588b-494d--ac8e-5c3978ba9150 _base compute_nodes locks

b6ba588b-494d-4055-ac8e-5c3978ba9150目录为虚拟机的ID(可通过nova list查看),详细内容如下
console.log 终端输出到此文件中
disk 虚拟磁盘,后端文件/var/lib/nova/instances/_base/fed362a98366776009c94e3d0856df41750b4353,使用的是copy on write模式,基础镜像就是这里的后端文件,只有变动的内容才放到disk文件中

[root@node2 b6ba588b-494d--ac8e-5c3978ba9150]# file disk
disk: QEMU QCOW Image (v3), has backing file (path /var/lib/nova/instances/_base/fed362a98366776009c94e3d0856df417), bytes [root@node2 b6ba588b-494d--ac8e-5c3978ba9150]# qemu-img info disk
image: disk
file format: qcow2
virtual size: .0G ( bytes)
disk size: 2.4M
cluster_size:
backing file: /var/lib/nova/instances/_base/fed362a98366776009c94e3d0856df41750b4353
Format specific information:
compat: 1.1
lazy refcounts: false

disk.info disk的详情
[root@node2 b6ba588b-494d-4055-ac8e-5c3978ba9150]# qemu-img info disk.info
image: disk.info
file format: raw
virtual size: 512 (512 bytes)
disk size: 4.0K

libvirt.xml 就是libvirt自动生成的xml,不可以改动此xml,因为改了也没什么卵用,此xml是启动虚拟机时动态生成的

compute_nodes记录了主机名和时间戳
[root@node2 instances]# cat compute_nodes
{"node2.chinasoft.com": 1493295366.200245}

locks目录:类似于写shell脚本时的lock文件
学习metadata

metadata(元数据)
在创建虚拟机时可以添加或者修改虚拟机的默认属性,例如主机名,key-pair,ip地址等
在新创建的虚拟机上查看metadata的数据,这些都是可以通过metadata生成
账号cirros
密码cubswin:)

[root@node2 instances]# ssh cirros@192.168.3.102
$ curl http://169.254.169.254/2009-04-04/meta-data
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
hostname
instance-action
instance-id
instance-type
local-hostname
local-ipv4
placement/
public-hostname
public-ipv4
public-keys/
reservation-id
security-groups 查看路由
$ ip ro li
default via 192.168.3.1 dev eth0
169.254.169.254 via 192.168.3.100 dev eth0
192.168.3.0/ dev eth0 src 192.168.3.102

在控制节点查看网络的命名空间ns

[root@node1 instances]# ip netns li
qdhcp-65c11cc3-8efb-46de-8d14-690431835bae (id: 0)

查看上述ns的具体网卡情况,也就是在命名空间中使用ip ad li并查看端口占用情况

[root@node1 instances]# ip netns exec qdhcp-65c11cc3-8efb-46de-8d14-690431835bae ip ad li
: lo: <LOOPBACK,UP,LOWER_UP> mtu qdisc noqueue state UNKNOWN qlen
link/loopback ::::: brd :::::
inet 127.0.0.1/ scope host lo
valid_lft forever preferred_lft forever
inet6 ::/ scope host
valid_lft forever preferred_lft forever
: ns-436a0452-af@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu qdisc noqueue state UP qlen
link/ether fa::3e:a3::b9 brd ff:ff:ff:ff:ff:ff link-netnsid
inet 192.168.3.100/ brd 192.168.3.255 scope global ns-436a0452-af
valid_lft forever preferred_lft forever
inet 169.254.169.254/ brd 169.254.255.255 scope global ns-436a0452-af
valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:fea3:76b9/ scope link
valid_lft forever preferred_lft forever [root@node1 instances]# ip netns exec qdhcp-65c11cc3-8efb-46de-8d14-690431835bae netstat -tunlp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0.0.0.0: 0.0.0.0:* LISTEN /python2
tcp 192.168.3.100: 0.0.0.0:* LISTEN /dnsmasq
tcp 169.254.169.254: 0.0.0.0:* LISTEN /dnsmasq
tcp6 fe80::f816:3eff:fea3: :::* LISTEN /dnsmasq
udp 192.168.3.100: 0.0.0.0:* /dnsmasq
udp 169.254.169.254: 0.0.0.0:* /dnsmasq
udp 0.0.0.0: 0.0.0.0:* /dnsmasq
udp6 fe80::f816:3eff:fea3: :::* /dnsmasq

总结
命名空间ns的ip地址dhcp服务分配的192.168.3.100而且还有一个169.254.169.254的ip,并在此启用了一个http服务(不仅提供http,还提供dns解析等),命名空间在neutron的dhcp-agent配置文件中启用了service_metadata_proxy = True而生效,
所以虚拟机的路由是命名空间通过dhcp推送(ip ro li查看出来的)的,key-pair就是通过命名空间在虚拟机生成时在/etc/rc.local中写一个curl的脚本把key-pair定位到.ssh目录下,并且改名即可,其他同理