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

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

五、深入理解Neutron

OpenStack实践系列⑦深入理解neutron和虚拟机_第1张图片

5.1 虚拟机网卡和网桥

[root@node1 ~]# ifconfig 
brq65c11cc3-8e: flags=4163 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 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 mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
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 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网络分类

OpenStack实践系列⑦深入理解neutron和虚拟机_第2张图片

5.2.2Openstack网络分层

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

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

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

OpenStack实践系列⑦深入理解neutron和虚拟机_第3张图片

 

多平面网络

OpenStack实践系列⑦深入理解neutron和虚拟机_第4张图片

混合平面私有网络

OpenStack实践系列⑦深入理解neutron和虚拟机_第5张图片

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

OpenStack实践系列⑦深入理解neutron和虚拟机_第6张图片

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

OpenStack实践系列⑦深入理解neutron和虚拟机_第7张图片

 

5.4 图解Neutron服务的几大组件

OpenStack实践系列⑦深入理解neutron和虚拟机_第8张图片

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:  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:  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目录下,并且改名即可,其他同理

 

你可能感兴趣的:(OpenStack实践系列⑦深入理解neutron和虚拟机)