应届生面试要点总结（14）OpenStack相关/根据简历

青旅半醒 2022-03-24 14:42 423阅读 0赞

IaaS（Infrastructure as a Service）提供的服务是虚拟机。 IaaS 负责管理虚机的生命周期，包括创建、修改、备份、启停、销毁等。 使用者从云平台得到的是一个已经安装好镜像（操作系统+其他预装软件）的虚拟机。 使用者需要关心虚机的类型（OS）和配置（CPU、内存、磁盘），并且自己负责部署上层的中间件和应用。 IaaS 的使用者通常是数据中心的系统管理员。 典型的 IaaS 例子有 AWS、Rackspace、阿里云等。

PaaS（Platform as a Service）提供的服务是应用的运行环境和一系列中间件服务（比如数据库、消息队列等）。 使用者只需专注应用的开发，并将自己的应用和数据部署到PaaS环境中。 PaaS负责保证这些服务的可用性和性能。 PaaS的使用者通常是应用的开发人员。 典型的 PaaS 有 Heroku、Google App Engine、IBM BlueMix 等。

SaaS（Software as a Service）提供的是应用服务。 使用者只需要登录并使用应用，无需关心应用使用什么技术实现，也不需要关系应用部署在哪里。 SaaS的使用者通常是应用的最终用户。 典型的 SaaS 有 Google Gmail、Salesforce 等。

Nova：管理 VM 的生命周期，是 OpenStack 中最核心的服务。

Neutron：为 OpenStack 提供网络连接服务，负责创建和管理L2、L3 网络，为 VM 提供虚拟网络和物理网络连接。

Glance：管理 VM 启动镜像，Nova 创建 VM 时将使用 Glance 提供的镜像。

Cinder：为 VM 提供块存储服务。Cinder 提供的每一个 Volume 在 VM 看来就是一块虚拟硬盘，一般用作数据盘。

Swift：提供对象存储服务。VM 可以通过 RESTful API 存放对象数据。作为可选的方案，Glance 可以将镜像存放在 Swift 中；Cinder 也可以将 Volume 备份到 Swift 中。

Keystone：为 OpenStack 的各种服务提供认证和权限管理服务。简单的说，OpenStack 上的每一个操作都必须通过 Keystone 的审核。

Ceilometer：提供 OpenStac k监控和计量服务，为报警、统计或计费提供数据。

Horizon：为 OpenStack 用户提供一个 Web 的自服务 Portal。

Keystone当点登录击时，OpenStack 内部发生了哪些事情？

Token 中包含了 User 的 Role 信息。请注意，顶部显示 admin 可访问的 Project 为 “admin” 和 “demo”。 其实在此之前发生了一些事情：

同时，admin 可以访问 Intance, Volume, Image 等服务。这是因为 admin 已经从 Keystone 拿到了各 Service 的 Endpoints。

点击 “Images”，会显示 image 列表。背后发生了这些事：首先 admin 将请求发送到 Glance 的 Endpoint，Glance 向 Keystone 询问 admin 身份是否有效，接下来 Glance 会查看 /etc/glance/policy.json 判断 admin 是否有查看 image 的权限，权限判定通过，Glance 将 image 列表发给 admin。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NFVVNVTkpN_size_16_color_FFFFFF_t_70][]

上面是 Glance 的架构图

glance-api 是系统后台运行的服务进程。 对外提供 REST API，响应 image 查询、获取和存储的调用。glance-api 不会真正处理请求。 如果操作是与 image metadata（元数据）相关，glance-api 会把请求转发给 glance-registry； 如果操作是与 image 自身存取相关，glance-api 会把请求转发给该 image 的 store backend。

glance-registry 是系统后台运行的服务进程。 负责处理和存取 image 的 metadata，例如 image 的大小和类型。在控制节点上可以查看 glance-registry 进程。

Image 的 metadata 会保持到 database 中，默认是 MySQL。 在控制节点上可以查看 glance 的 database 信息。

Glance 自己并不存储 image。 真正的 image 是存放在 backend 中的。 Glance 支持多种 backend，包括：

A directory on a local file system（这是默认配置）

GridFS

Ceph RBD

Amazon S3

Sheepdog

OpenStack Block Storage (Cinder)

OpenStack Object Storage (Swift)

VMware ESX

具体使用哪种 backend，是在 /etc/glance/glance-api.conf 中配置的。

nova-api：接收和响应客户的 API 调用。 除了提供 OpenStack 自己的API，nova-api 还支持 Amazon EC2 API。

nova-scheduler：虚机调度服务，负责决定在哪个计算节点上运行虚机。

nova-compute：管理虚机的核心服务，通过调用 Hypervisor API 实现虚机生命周期管理。定时向 OpenStack 报告计算节点的状态。

Hypervisor：计算节点上跑的虚拟化管理程序，虚机管理最底层的程序。 不同虚拟化技术提供自己的 Hypervisor。 常用的 Hypervisor 有 KVM，Xen， VMWare 等。

nova-conductor：nova-compute 经常需要更新数据库，比如更新虚机的状态。 出于安全性和伸缩性的考虑，nova-compute 并不会直接访问数据库，而是将这个任务委托给 nova-conductor。

nova-console：用户可以通过多种方式访问虚机的控制台；nova-novncproxy，基于 Web 浏览器的 VNC 访问；nova-spicehtml5proxy，基于 HTML5 浏览器的 SPICE 访问；nova-xvpnvncproxy，基于 Java 客户端的 VNC 访问。

nova-consoleauth：负责对访问虚机控制台请求提供 Token 认证。nova-cert：提供 x509 证书支持。

nova-api 是整个 Nova 组件的门户，所有对 Nova 的请求都首先由 nova-api 处理。nova-api 向外界暴露若干 HTTP REST API 接口 在 keystone 中我们可以查询 nova-api 的 endponits。客户端就可以将请求发送到 endponits 指定的地址，向 nova-api 请求操作。 当然，作为最终用户的我们不会直接发送 Rest API请求。 OpenStack CLI，Dashboard 和其他需要跟 Nova 交换的组件会使用这些 API。

Nova-api 对接收到的 HTTP API 请求会做如下处理：检查客户端传入的参数是否合法有效；调用 Nova 其他子服务的处理客户端 HTTP 请求；格式化 Nova 其他子服务返回的结果并返回给客户端。

nova-api 接收哪些请求：简单的说，只要是跟虚拟机生命周期相关的操作，nova-api 都可以响应。 大部分操作都可以在 Dashboard 上找到。

nova-compute 需要获取和更新数据库中 instance 的信息。但 nova-compute 并不会直接访问数据库，而是通过 nova-conductor 实现数据的访问。这样做有两个显著好处：更高的系统安全性，更好的系统伸缩性。

更高的安全性：在 OpenStack 的早期版本中，nova-compute 可以直接访问数据库，但这样存在非常大的安全隐患。因为 nova-compute 这个服务是部署在计算节点上的，为了能够访问控制节点上的数据库，就必须在计算节点的 /etc/nova/nova.conf 中配置访问数据库的连接信息，试想任意一个计算节点被黑客入侵，都会导致部署在控制节点上的数据库面临极大风险。

为了解决这个问题，从 G 版本开始，Nova 引入了一个新服务 nova-conductor，将 nova-compute 访问数据库的全部操作都放到 nova-conductor 中，而且 nova-conductor 是部署在控制节点上的。 这样就避免了 nova-compute 直接访问数据库，增加了系统的安全性。

更好的伸缩性：nova-conductor 将 nova-compute 与数据库解耦之后还带来另一个好处：提高了 nova 的伸缩性。nova-compute 与 conductor 是通过消息中间件交互的。这种松散的架构允许配置多个 nova-conductor 实例。 在一个大规模的 OpenStack 部署环境里，管理员可以通过增加 nova-conductor 的数量来应对日益增长的计算节点对数据库的访问。

openstack的计算节点默认过载是CPU是原来的16倍，内存1.5倍，磁盘1.0。KVM 允许 overcommit，这个特性使得虚机能够充分利用宿主机的 CPU 资源，但前提是在同一时刻，不是所有的虚机都满负荷运行。

内存超配原理 ：在物理机上的内存也是可以超配的，即虚拟机配置的内存总和可以大于物理机内存的总和。内存超配可不能像CPU那样通过时间片的复用，失去的记忆，哪怕是1毫秒，都是无法恢复的，所以内存的超配只能由VMM管理下，采用一些自我挖潜力的方法：

页面交换：虚拟机长时间未访问的内存内容被置换到存储中，并建立映射，当虚拟机再次访问该内存内容时再置换回来。

内存气泡：VMM通过内存气泡将较为空闲的虚拟机内存释放给内存使用率较高的虚拟机，从而提升内存利用率。

透明页共享：虚拟机之间共享同一物理内存空间（如同一物理机下的不同虚拟机安装了相同的操作系统），此时虚拟机仅对内存做只读操作（蓝色）。当虚拟机需要对内存进行写操作时，开辟另一内存空间，并修改映射（红色）。

页面压缩：将不太使用的内存数据进行压缩，存入压缩内存，系统需要使用的时候，在压缩内存寻找并解压缩，供应用使用。

内存的超配会给系统带来一定风险，当配置失误或运行内存超过物理内存，会导致虚拟机崩溃甚至影响物理机，说以内配的超配请谨慎。

依次经过 9 个 filter 的过滤（RetryFilter, AvailabilityZoneFilter, RamFilter, DiskFilter, ComputeFilter, ComputeCapabilitiesFilter, ImagePropertiesFilter, ServerGroupAntiAffinityFilter, ServerGroupAffinityFilter）

nova-compute 在计算节点上运行，负责管理节点上的 instance。 OpenStack 对 instance 的操作，最后都是交给 nova-compute 来完成的。 nova-compute 与 Hypervisor 一起实现 OpenStack 对 instance 生命周期的管理。

nova-compute 的功能可以分为两类：定时向 OpenStack 报告计算节点的状态，实现 instance 生命周期的管理。

当 nova-scheduler 选定了部署 instance 的计算节点后，会通过消息中间件 rabbitMQ 向选定的计算节点发出 launch instance 的命令。 该计算节点上运行的 nova-compute 收到消息后会执行 instance 创建操作。

nova-compute 创建 instance 的过程可以分为 4 步：为 instance 准备资源，创建 instance 的镜像文件，创建 instance 的 XML 定义文件，创建虚拟网络并启动虚拟机。

Neutron 为整个 OpenStack 环境提供网络支持，包括二层交换，三层路由，负载均衡，防火墙和 VPN 等。Neutron 提供了一个灵活的框架，通过配置，无论是开源还是商业软件都可以被用来实现这些功能。

二层交换 Switching：Nova 的 Instance 是通过虚拟交换机连接到虚拟二层网络的。Neutron 支持多种虚拟交换机，包括 Linux 原生的 Linux Bridge 和 Open vSwitch。 Open vSwitch（OVS）是一个开源的虚拟交换机，它支持标准的管理接口和协议。

利用 Linux Bridge 和 OVS，Neutron 除了可以创建传统的 VLAN 网络，还可以创建基于隧道技术的 Overlay 网络，比如 VxLAN 和 GRE（Linux Bridge 目前只支持 VxLAN）。

三层路由 Routing：Instance 可以配置不同网段的 IP，Neutron 的 router（虚拟路由器）实现 instance 跨网段通信。router 通过 IP forwarding，iptables 等技术来实现路由和 NAT。我们将在后面章节讨论如何在 Neutron 中配置 router 来实现 instance 之间，以及与外部网络的通信。

network 是一个隔离的二层广播域。Neutron 支持多种类型的 network，包括 local, flat, VLAN, VxLAN 和 GRE。

local：local 网络与其他网络和节点隔离。local 网络中的 instance 只能与位于同一节点上同一网络的 instance 通信，local 网络主要用于单机测试。

flat：flat 网络是无 vlan tagging 的网络。flat 网络中的 instance 能与位于同一网络的 instance 通信，并且可以跨多个节点。

vlan：vlan 网络是具有 802.1q tagging 的网络。vlan 是一个二层的广播域，同一 vlan 中的 instance 可以通信，不同 vlan 只能通过 router 通信。vlan 网络可跨节点，是应用最广泛的网络类型。

vxlan：vxlan 是基于隧道技术的 overlay 网络。vxlan 网络通过唯一的 segmentation ID（也叫 VNI）与其他 vxlan 网络区分。vxlan 中数据包会通过 VNI 封装成 UDP 包进行传输。因为二层的包通过封装在三层传输，能够克服 vlan 和物理网络基础设施的限制。

gre：gre 是与 vxlan 类似的一种 overlay 网络。主要区别在于使用 IP 包而非 UDP 进行封装。

subnet 是一个 IPv4 或者 IPv6 地址段。instance 的 IP 从 subnet 中分配。每个 subnet 需要定义 IP 地址的范围和掩码。network 与 subnet 是 1对多 关系。一个 subnet 只能属于某个 network；一个 network 可以有多个 subnet，这些 subnet 可以是不同的 IP 段，但不能重叠。

port 可以看做虚拟交换机上的一个端口。port 上定义了 MAC 地址和 IP 地址，当 instance 的虚拟网卡 VIF（Virtual Interface） 绑定到 port 时，port 会将 MAC 和 IP 分配给 VIF。subnet 与 port 是 1对多 关系。一个 port 必须属于某个 subnet；一个 subnet 可以有多个 port。

Neutron 由如下组件构成：

Neutron Server：对外提供 OpenStack 网络 API，接收请求，并调用 Plugin 处理请求。

Plugin：处理 Neutron Server 发来的请求，维护 OpenStack 逻辑网络状态， 并调用 Agent 处理请求。

Agent：处理 Plugin 的请求，负责在 network provider 上真正实现各种网络功能。

network provider：提供网络服务的虚拟或物理网络设备，例如 Linux Bridge，Open vSwitch 或者其他支持 Neutron 的物理交换机。

Queue：Neutron Server，Plugin 和 Agent 之间通过 Messaging Queue 通信和调用。

Database：存放 OpenStack 的网络状态信息，包括 Network, Subnet, Port, Router 等。

以创建一个 VLAN100 的 network 为例，假设 network provider 是 linux bridge， 流程如下：

Neutron Server 接收到创建 network 的请求，通过 Message Queue（RabbitMQ）通知已注册的 Linux Bridge Plugin。

Plugin 将要创建的 network 的信息（例如名称、VLAN ID等）保存到数据库中，并通过 Message Queue 通知运行在各节点上的 Agent。

Agent 收到消息后会在节点上的物理网卡（比如 eth2）上创建 VLAN 设备（比如 eth2.100），并创建 bridge （比如 brqXXX） 桥接 VLAN 设备。

Neutron Server 的分层结构，至上而下依次为：

Core API：对外提供管理 network, subnet 和 port 的 RESTful API。

Extension API：对外提供管理 router, load balance, firewall 等资源 的 RESTful API。

Commnon Service：认证和校验 API 请求。

Neutron Core：Neutron server 的核心处理程序，通过调用相应的 Plugin 处理请求。

Core Plugin API：定义了 Core Plgin 的抽象功能集合，Neutron Core 通过该 API 调用相应的 Core Plgin。

Extension Plugin API：定义了 Service Plgin 的抽象功能集合，Neutron Core 通过该 API 调用相应的 Service Plgin。

Core Plugin：实现了 Core Plugin API，在数据库中维护 network, subnet 和 port 的状态，并负责调用相应的 agent 在 network provider 上执行相关操作，比如创建 network。

Service Plugin：实现了 Extension Plugin API，在数据库中维护 router, load balance, security group 等资源的状态，并负责调用相应的 agent 在 network provider 上执行相关操作，比如创建 router。

归纳起来，Neutron Server 包括两部分：1. 提供 API 服务。2. 运行 Plugin。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NFVVNVTkpN_size_16_color_FFFFFF_t_70 1][]

Neutron 通过 plugin 和 agent 提供的网络服务。plugin 位于 Neutron server，包括 core plugin 和 service plugin。agent 位于各个节点，负责实现网络服务。core plugin 提供 L2 功能，ML2 是推荐的 plugin。使用最广泛的 L2 agent 是 linux bridage 和 open vswitch。service plugin 和 agent 提供扩展功能，包括 dhcp, routing, load balance, firewall, vpn 等。

目前 linux bridge 只支持 vxlan，不支持 gre；open vswitch 两者都支持。VXLAN 全称 Virtual eXtensible Local Area Network。

VXLAN 有下面几个优势：

1. 支持更多的二层网段。VLAN 使用 12-bit 标记 VLAN ID，最多支持 4094 个 VLAN，这对大型云部署会成为瓶颈。VXLAN 的 ID （VNI 或者 VNID）则用 24-bit 标记，支持 16777216 个二层网段。

2. 能更好地利用已有的网络路径。VLAN 使用 Spanning Tree Protocol 避免环路，这会导致有一半的网络路径被 block 掉。VXLAN 的数据包是封装到 UDP 通过三层传输和转发的，可以使用所有的路径。

3. 避免物理交换机 MAC 表耗尽。由于采用隧道机制，TOR (Top on Rack) 交换机无需在 MAC 表中记录虚拟机的信息。

VXLAN 是将二层建立在三层上的网络。 通过将二层数据封装到 UDP 的方式来扩展数据中心的二层网段数量。 VXLAN 是一种在现有物理网络设施中支持大规模多租户网络环境的解决方案。 VXLAN 的传输协议是 IP + UDP。

VXLAN 定义了一个 MAC-in-UDP 的封装格式。 在原始的 Layer 2 网络包前加上 VXLAN header，然后放到 UDP 和 IP 包中。 通过 MAC-in-UDP 封装，VXLAN 能够在 Layer 3 网络上建立起了一条 Layer 2 的隧道。

VXLAN 使用 VXLAN tunnel endpoint (VTEP) 设备处理 VXLAN 的封装和解封。每个 VTEP 有一个 IP interface，配置了一个 IP 地址。VTEP 使用该 IP 封装 Layer 2 frame，并通过该 IP interface 传输和接收封装后的 VXLAN 数据包。

VXLAN 独立于底层的网络拓扑；反过来，两个 VTEP 之间的底层 IP 网络也独立于 VXLAN。VXLAN 数据包是根据外层的 IP header 路由的，该 header 将两端的 VTEP IP 作为源和目标 IP。

数据传输过程如下：

1. Host-A 向 Host-B 发送数据时，Host-B 的 MAC 和 IP 作为数据包的目标 MAC 和 IP，Host-A 的 MAC 作为数据包的源 MAC 和 IP，然后通过 VTEP-1 将数据发送出去。

2. VTEP-1 从自己维护的映射表中找到 MAC-B 对应的 VTEP-2，然后执行 VXLAN 封装，加上 VXLAN 头，UDP 头，以及外层 IP 和 MAC 头。此时的外层 IP 头，目标地址为 VTEP-2 的 IP，源地址为 VTEP-1 的 IP。同时由于下一跳是 Router-1，所以外层 MAC 头中目标地址为 Router-1 的 MAC。

3. 数据包从 VTEP-1 发送出后，外部网络的路由器会依据外层 IP 头进行路由，最后到达与 VTEP-2 连接的路由器 Router-2。

4. Router-2 将数据包发送给 VTEP-2。VTEP-2 负责解封数据包，依次去掉外层 MAC 头，外层 IP 头，UDP 头 和 VXLAN 头。VTEP-2 依据目标 MAC 地址将数据包发送给 Host-B。

上面的流程我们看到 VTEP 是 VXLAN 的最核心组件，负责数据的封装和解封。

隧道也是建立在 VTEP 之间的，VTEP 负责数据的传送。

VTEP 可以由专有硬件来实现，也可以使用纯软件实现。目前比较成熟的 VTEP 软件实现包括：1. 带 VXLAN 内核模块的 Linux。2. Open vSwitch。

1. Linux vxlan 创建一个 UDP Socket，默认在 8472 端口监听。

2. Linux vxlan 在 UDP socket 上接收到 vxlan 包后，解包，然后根据其中的 vxlan ID 将它转给某个 vxlan interface，然后再通过它所连接的 linux bridge 转给虚机。

3. Linux vxlan 在收到虚机发来的数据包后，将其封装为多播 UDP 包，从网卡发出。

一个flat类型的网络就是一张物理网卡上绑一个linuxbridge，一个flat网络占用物理机一张物理网卡。

vlan网络，创建一个新的vlan网络，实际上是在隧道网络的那张网卡上分一个网卡出来比如eth1.100。那再创建一个vlan网络，再从eth1上分一个eth1.101。然后每个eth1.xxx上挂一个linuxbridge，这样的话，同一个vlan（一个linuxbridge上）的网络里的vm之间互通，跟不同vlan上的虚拟机不通 。

L2 Population的作用是在VTEP上提供Porxy ARP功能，使得VTEP能够预先获知VXLAN网络中如下信息：1.VM IP -- MAC对应关系。2. VM -- VTEP的对应关系。

当 VM A 需要与 VM G 通信时：

1. Host 1 上的VTEP直接响应 VM A的APR请求，告之 VM G 的 MAC 地址。

2. 因为 Host 1 上的 VTEP 知道 VM G 位于 Host 4，会将封装好的 VXLAN 数据包直接发送给 Host 4 的 VTEP。

这样就解决了 MAC 地址学习和 APR 广播的问题，从而保证了 VXLAN 的 Scalability。那么下一个关键问题是：VTEP 是如何提前获知 IP -- MAC -- VTEP 相关信息的呢？

Neutron 知道每一个 port 的状态和信息； port 保存了 IP，MAC 相关数据。instance 启动时，其 port 状态变化过程为：down -> build -> active。每当 port 状态发生变化时，Neutron 都会通过 RPC 消息通知各节点上的 Neutron agent，使得 VTEP 能够更新 VM 和 port 的相关信息。VTEP 可以根据这些信息判断出其他 Host 上都有哪些 VM，以及它们的 MAC 地址，这样就能直接与之通信，从而避免了不必要的隧道连接和广播。

安全组（Security Group）和虚拟防火墙。安全组的原理是通过 iptables 对 instance 所在计算节点的网络流量进行过滤。虚拟防火墙则由 Neutron Firewall as a Service（FWaaS）高级服务提供。 其底层也是使用 iptables，在 Neutron Router 上对网络包进行过滤。

安全组有以下特性：1. 通过宿主机上 iptables 规则控制进出 instance 的流量。2. 安全组作用在 instance 的 port 上。3. 安全组的规则都是 allow，不能定义 deny 的规则。4. instance 可应用多个安全组叠加使用这些安全组中的规则。

Firewall as a Service（FWaaS）是 Neutron 的一个高级服务。用户可以用它来创建和管理防火墙，在 subnet 的边界上对 layer 3 和 layer 4 的流量进行过滤。传统网络中的防火墙一般放在网关上，用来控制子网之间的访问。 FWaaS 的原理也一样，是在 Neutron 虚拟 router 上应用防火墙规则，控制进出租户网络的数据。

FWaaS 有三个重要概念： Firewall、Policy 和 Rule。Firewall：租户能够创建和管理的逻辑防火墙资源。 Firewall 必须关联某个 Policy，因此必须先创建 Policy。Firewall Policy：Policy 是 Rule 的集合，Firewall 会按顺序应用 Policy 中的每一条 Rule。Firewall Rule：Rule 是访问控制的规则，由源与目的子网 IP、源与目的端口、协议、allow 或 deny 动作组成。

例如，我们可以创建一条 Rule，允许外部网络通过 ssh 访问租户网络中的 instance，端口为 22。

区别：安全组的应用对象是虚拟网卡，由 L2 Agent 实现，比如 neutron\_openvswitch\_agent 和 neutron\_linuxbridge\_agent。安全组会在计算节点上通过 iptables 规则来控制进出 instance 虚拟网卡的流量。也就是说：安全组保护的是 instance。FWaaS 的应用对象是 router，可以在安全组之前控制外部过来的流量，但是对于同一个 subnet 内的流量不作限制。也就是说：FWaaS 保护的是 subnet。所以，可以同时部署 FWaaS 和安全组实现双重防护。

FWaaS 用于加强 Neutron 网络的安全性，与安全组可以配合使用。 下面将 FWaaS 和安全组做个比较。

相同点： 1. 底层都是通过 iptables 实现。

不同点： 1. FWaaS 的 iptables 规则应用在 router 上，保护整个租户网络；安全组则应用在虚拟网卡上，保护单个 instance。2. FWaaS 可以定义 allow 或者 deny 规则；安全组只能定义 allow 规则。3. 目前 FWaaS 规则不能区分进出流量，对双向流量都起作用；安全组规则可以区分 ingress 和 egress。

DHCP过程有点像TCP建立连接的感觉：

1、instance发送DHCPDISCOVER广播包，广播域内都能收到

2、广播到达LInux-bridge 会通过dhcp端口到达一个叫veth-pair的设备，veth-pair连接到dnsmasq，dnsmasq会检查host文件，查看mac地址有没有对应项，发现有，然后通过DHCPOFFER将IP、子网掩码等信息发给instance

3、instance收到后发送DHCPREQUEST确认收到

4、dnsmasq发送DHCPPACK确认消息

当租户网络连接到 Neutron router，通常将 router 作为默认网关。 当 router 接收到 instance 的数据包，并将其转发到外网时：router 会修改包的源地址为自己的外网地址，这样确保数据包转发到外网，并能够从外网返回。

router 修改返回的数据包，并转发给真正的 instance。这个行为被称作 Source NAT。如果需要从外网直接访问 instance，则可以利用 floating IP。

下面是关于 floating IP 必须知道的事实：floating IP 提供静态 NAT 功能，建立外网 IP 与 instance 租户网络 IP 的一对一映射。floating IP 是配置在 router 提供网关的外网 interface 上的，而非 instance 中。router 会根据通信的方向修改数据包的源或者目的地址。

1. floating IP 能够让外网直接访问租户网络中的 instance。这是通过在 router 上应用 iptalbes 的 NAT 规则实现的。

2. floating IP 是配置在 router 的外网 interface 上的，而非 instance。

Docker与vm的区别，docker是什么。docker和OS虚拟机有什么区别。虚拟机是在宿主操作系统之上有自己的内核。而docker都是使用宿主操作系统的内核。所以docker启动很快。docker为什么细粒度。为什么轻量，Vm是在主操作系统上运行多个不同的操作系统，而docker通过docker 后台进程直接运行在宿主机上。Vm的Hypervisor会对硬件资源进行虚拟化，docker直接使用硬件资源，所以资源利用率相对docker低。在启动方面，docker在几秒钟可以创建大量容器，它们的启动速度是在数量级上的差距。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NFVVNVTkpN_size_16_color_FFFFFF_t_70]: /images/20220323/88a1eeb850234611a0d3ca5b930547c6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NFVVNVTkpN_size_16_color_FFFFFF_t_70 1]: /images/20220323/f4b2bdc9483448ea878e2042e9ad2673.png