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

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

五、深入理解Neutron

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网络分类

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