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