OpenStack实践系列⑦深入理解neutron和虚拟机
OpenStack实践系列⑦深入理解neutron和虚拟机
五、深入理解Neutron
5.1 虚拟机网卡和网桥
[root@node1 ~]# ifconfig brq65c11cc3-8e: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.3.199 netmask 255.255.255.0 broadcast 192.168.3.255 ether 00:50:56:3b:dc:7e txqueuelen 1000 (Ethernet) RX packets 1790597 bytes 176851434 (168.6 MiB) RX errors 0 dropped 3 overruns 0 frame 0 TX packets 124754 bytes 46878133 (44.7 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 ether 00:50:56:3b:dc:7e txqueuelen 1000 (Ethernet) RX packets 3293092 bytes 1095327590 (1.0 GiB) RX errors 0 dropped 15 overruns 0 frame 0 TX packets 140212 bytes 54058900 (51.5 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1 (Local Loopback) RX packets 771917 bytes 210969292 (201.1 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 771917 bytes 210969292 (201.1 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 tap436a0452-af: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 ether 4a:a6:af:6e:63:47 txqueuelen 1000 (Ethernet) RX packets 11140 bytes 1616336 (1.5 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1660822 bytes 165849927 (158.1 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 [root@node1 ~]# brctl show bridge name bridge id STP enabled interfaces brq65c11cc3-8e 8000.0050563bdc7e no eth0 tap436a0452-af brq65c11cc3-8e(网桥):可以理解为一个小交换机,网桥上的设备都和eth0能通(数据链路层),其中tap436a0452-af作为虚拟机的网卡,从而实现通信
5.2 不同场景网络类型和OpenStack网络分层
5.2.1 Openstack网络分类
5.2.2Openstack网络分层
首先网络分层肯定是基于OSI七层模型的,在这里就不在赘述,只对Openstack的网络进行分层讲解
网络:在实际的物理环境下,我们使用交换机或者集线器把多个计算机连接起来形成了网络,在Neutron的世界里,网络也是将多个不同的云主机连接起来。
子网:在实际的物理环境下,在一个网络中,我们可以将网络划分成多个逻辑子网,在Neutron的世界里,子网也是路属于网络下的
端口:在实际的物理环境下,每个字子网或者每个网络,都有很多的端口,比如交换机端口来供计算机链接,在Neutron的世界里端口也是隶属于子网下,云主机的网卡会对应到一个端口上。
路由器:在实际的网络环境下,不同网络或者不同逻辑子网之间如果需要进行通信,需要通过路由器进行路由,在Neutron的实际里路由也是这个作用,用来连接不同的网络或者子网。
5.3 五种neutron常见的模型
单一平面网络(也叫大二层网络,最初的 nova-network 网络模型)
单一平面网络的缺点:
a.存在单一网络瓶颈,缺乏可伸缩性。
b.缺乏合适的多租户隔离。
c.容易发生广播风暴,而且不能使用keepalived(vrrp组播)
多平面网络
混合平面私有网络
通过私有网络实现运营商路由功能
通过私有网络实现每个租户创建自己专属的网络区段
5.4 图解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-4055-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-4055-ac8e-5c3978ba9150]# file disk disk: QEMU QCOW Image (v3), has backing file (path /var/lib/nova/instances/_base/fed362a98366776009c94e3d0856df417), 1073741824 bytes [root@node2 b6ba588b-494d-4055-ac8e-5c3978ba9150]# qemu-img info disk image: disk file format: qcow2 virtual size: 1.0G (1073741824 bytes) disk size: 2.4M cluster_size: 65536 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/24 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 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ns-436a0452-af@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000 link/ether fa:16:3e:a3:76:b9 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 192.168.3.100/24 brd 192.168.3.255 scope global ns-436a0452-af valid_lft forever preferred_lft forever inet 169.254.169.254/16 brd 169.254.255.255 scope global ns-436a0452-af valid_lft forever preferred_lft forever inet6 fe80::f816:3eff:fea3:76b9/64 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:80 0.0.0.0:* LISTEN 2867/python2 tcp 0 0 192.168.3.100:53 0.0.0.0:* LISTEN 10450/dnsmasq tcp 0 0 169.254.169.254:53 0.0.0.0:* LISTEN 10450/dnsmasq tcp6 0 0 fe80::f816:3eff:fea3:53 :::* LISTEN 10450/dnsmasq udp 0 0 192.168.3.100:53 0.0.0.0:* 10450/dnsmasq udp 0 0 169.254.169.254:53 0.0.0.0:* 10450/dnsmasq udp 0 0 0.0.0.0:67 0.0.0.0:* 10450/dnsmasq udp6 0 0 fe80::f816:3eff:fea3:53 :::* 10450/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目录下,并且改名即可,其他同理