首页 文章 精选 留言 我的

精选列表

搜索[分代式],共10000篇文章
优秀的个人博客,低调大师

配置 DHCP 服务 - 每天5分钟玩转 OpenStack(89)

前面章节我们看到 instance 在启动过程中能够从 Neutron 的 DHCP 服务获得 IP,本节将详细讨论其内部实现机制。 Neutron 提供 DHCP 服务的组件是 DHCP agent。 DHCP agent 在网络节点运行上,默认通过 dnsmasq 实现 DHCP 功能。 配置 DHCP agent DHCP agent 的配置文件位于 /etc/neutron/dhcp_agent.ini。 dhcp_driver使用 dnsmasq 实现 DHCP。 interface_driver使用 linux bridge 连接 DHCP namespace interface。 当创建 network 并在 subnet 上 enable DHCP 时,网络节点上的 DHCP agent 会启动一个 dnsmasq 进程为该 network 提供 DHCP 服务。 dnsmasq 是一个提供 DHCP 和 DNS 服务的开源软件。 dnsmasq 与 network 是一对一关系,一个 dnsmasq 进程可以为同一 netowrk 中所有 enable 了 DHCP 的 subnet 提供服务。 回到我们的实验环境,之前创建了 flat_net,并且在 subnet 上启用了 DHCP,执行 ps 查看 dnsmasq 进程,如下图所示: DHCP agent 会为每个 network 创建一个目录 /opt/stack/data/neutron/dhcp/,用于存放该 network 的 dnsmasq 配置文件。 下面讨论 dnsmasq 重要的启动参数: --dhcp-hostsfile存放 DHCP host 信息的文件,这里的 host 在我们这里实际上就是 instance。 dnsmasq 从该文件获取 host 的 IP 与 MAC 的对应关系。 每个 host 对应一个条目,信息来源于 Neutron 数据库。 对于 flat_net,hostsfile 是 /opt/stack/data/neutron/dhcp/f153b42f-c3a1-4b6c-8865-c09b5b2aa274/host,记录了 DHCP,cirros-vm1 和 cirros-vm2 的 interface 信息。 --interface指定提供 DHCP 服务的 interface。 dnsmasq 会在该 interface 上监听 instance 的 DHCP 请求。 对于 flat_net,interface 是 ns-19a0ed3d-fe。 或许大家还记得,之前我们看到的 DHCP interface 叫 tap19a0ed3d-fe(如下图所示),并非 ns-19a0ed3d-fe。 从名称上看,ns-19a0ed3d-fe 和 tap19a0ed3d-fe 应该存在某种联系,但那是什么呢? 要回答这个问题,需要先搞懂一个概念:Linux Network Namespace,我们下一节详细讨论。

优秀的个人博客,低调大师

创建 flat network - 每天5分钟玩转 OpenStack(87)

上一节我们讨论了 flat network 的原理,今天就来创建 "flat_net" 并分析底层网络的实现。 打开菜单 Admin -> Networks,点击 “Create Network” 按钮。 显示创建页面。 Provider Network Type 选择 “Flat”。 Physical Network 填写 “default”,与 ml2_conf.ini 中 flat_networks 参数保持一致。 点击 “Create Network”,flat_net 创建成功。 点击 flat_net 链接,进入 network 配置页面,目前还没有 subnet,点击 “Create Subnet” 按钮。 设置 IP 地址为 “172.16.1.0/24”。 点击 “Next”,设置 IP 地址范围为 172.16.1.101-172.16.1.200。 点击 “Create”,subnet 创建成功。 底层网络发生了什么变化 执行 brctl show,查看控制节点当前的网络结构。 Neutron 自动新建了 flat_net 对应的网桥 brqf153b42f-c3,以及 dhcp 的 tap 设备 tap19a0ed3d-fe。 另外,tap19a0ed3d-fe 和物理网卡 eth1 都已经连接到 bridge。 此时 flat_net 结构如图所示: flat_net准备就绪,下一节将部署 instance 到此 flat 网络。

优秀的个人博客,低调大师

Service Plugin / Agent - 每天5分钟玩转 OpenStack(73)

Core Plugin/Agent 负责管理核心实体:net, subnet 和 port。而对于更高级的网络服务,则由 Service Plugin/Agent 管理。Service Plugin 及其 Agent 提供更丰富的扩展功能,包括路由,load balance,firewall等,如图所示: DHCPdhcp agent 通过 dnsmasq 为 instance 提供 dhcp 服务。 Routingl3 agent 可以为 project(租户)创建 router,提供 Neutron subnet 之间的路由服务。路由功能默认通过 IPtables 实现。 Firewalll3 agent 可以在 router 上配置防火墙策略,提供网络安全防护。 另一个与安全相关的功能是 Security Group,也是通过 IPtables 实现。 Firewall 与 Security Group 的区别在于: Firewall 安全策略位于 router,保护的是某个 project 的所有 network。 Security Group 安全策略位于 instance,保护的是单个 instance。 Firewall 与 Security Group 后面会详细分析。 Load BalanceNeutron 默认通过 HAProxy 为 project 中的多个 instance 提供 load balance 服务。 后面的章节会结合 linux bridge 和 open vswitch 详细讨论每一种 service。 至此,我们已经学习了 Core 和 Service Plugin/Agent,下一节将对 Neutron 架构做个小结。

优秀的个人博客,低调大师

Boot from Volume - 每天5分钟玩转 OpenStack(61)

Volume 除了可以用作 instance 的数据盘,也可以作为启动盘(Bootable Volume),那么如何使 volume 成为 bootable 呢? 现在我们打开 instance 的 launch 操作界面。 这里有一个下拉菜单“Instance Boot Source”。以前我们 launch instance 要么直接从 image launch(Boot from image),要么从 instance 的 snapshot launch(Boot from snapshot)。 这两种 launch 方式下,instance 的启动盘 vda 均为镜像文件,存放路径为计算节点 /opt/stack/data/nova/instances/<Instance ID>/disk,例如: 下拉列表的后三项则可以将 volume 作为 instance 的启动盘 vda,分别为: Boot from volume直接从现有的 bootable volume launch Boot from image (create a new volume)创建一个新的 volume,将 image 的数据 copy 到 volume,然后从该 volume launch Boot from volume snapshot (create a new volume)通过指定的 volume snapshot 创建 volume,然后从该 volume launch,当然前提是该snapshot 对应的源 volume 是 bootable 的。 下面我们以 Boot from image (create a new volume)为例,看如何从 volume 启动。 选择 cirros 作为 image,instance 命名为“c3” 如果希望 terminate instance 的时候同时删除 volume,可以勾选“Delete on Terminate” c3 成功 Launch 后,volume 列表中可以看到一个新 bootable volume,以 volume ID 命名,并且已经 attach 到 c3。 该 volume 已经配置为 c3 的启动盘 vda。 如果用该 volume 创建 snapshot,之后就可以通过 Boot from volume snapshot (create a new volume) 部署新的 instance,这个操作留给大家练习。 这里再给大家留个练习:boot from volume 的 instance 也可以执行 live migrate,请大家思考一下 volume 是如何 migrate 到目标节点的,并通过日志验证。 到这里,cinder 的主要操作就讲解完了。前面的实验使用的是 LVM provider,cinder 当然也支持其他 provider。为了让大家对这点有感性认识,下一节我们将接入 NFS volume provider。

优秀的个人博客,低调大师

Restore Volume 操作 - 每天5分钟玩转 OpenStack(60)

前面我们 backup 了 voluem,今天我们将讨论如何 restore volume。 restore 的过程其实很简单,两步走: 在存储节点上创建一个空白 volume。 将 backup 的数据 copy 到空白 voluem 上。 下面我们来看 restore 操作的详细流程: 向 cinder-api 发送 restore 请求 cinder-api 发送消息 cinder-scheduler 挑选最合适的 cinder-volume cinder-volume 创建空白 volume cinder-backup 将 backup 数据 copy 到空白 volume 上 我们先来看第 1 步。 向 cinder-api 发送 restore 请求 客户(可以是 OpenStack 最终用户,也可以是其他程序)向 cinder-api 发送请求:“请 restore 指定的 backup。这里我们将 restore 之前创建的 backup。 目前 restore 只能在 CLI 中执行。 cinder-api 接收到 restore 请求。日志文件在 /opt/stack/logs/c-api.log。 这里看到 cinder-api 转发请求,为 restore 创建 volume。 之后 cinder-scheduler 和 cinder-volume 将创建空白 volume,这个过程与 create volume 一样,不再赘述。 接下来分析数据恢复的过程。 首先,在 cinder-api 日志中可以看到相关信息。 这里注意日志中的 volume_id 和 backup_id 与前面 backup-restore 命令的输出是一致的。 下面来看 cinder-backup 是如何恢复数据的。 cinder-backup 执行 restore 操作 日志为 /opt/stack/logs/c-vol.log。 启动 restore 操作,mount NFS。 读取 container 目录中的 metadata。 将数据解压并写到 volume 中。 恢复 volume 的 metadata,完成 restore 操作。 此时,在 GUI 中已经可以看到 restore 创建的 volume。 以上就是 volume restore 的分析,下一节我们讨论如何将 volume 作为 instance 的启动盘。

优秀的个人博客,低调大师

Backup Volume 操作 - 每天5分钟玩转 OpenStack(59)

本节我们讨论 volume 的 Backup 操作。 Backup 是将 volume 备份到别的地方(备份设备),将来可以通过 restore 操作恢复。 Backup VS Snapshot 初看 backup 功能好像与 snapshot 很相似,都可以保存 volume 的当前状态,以备以后恢复。但二者在用途和实现上还是有区别的,具体表现在: Snapshot 依赖于源 volume,不能独立存在;而 backup 不依赖源 volume,即便源 volume 不存在了,也可以 restore。 Snapshot 与源 volume 通常存放在一起,都由同一个 volume provider 管理;而 backup 存放在独立的备份设备中,有自己的备份方案和实现,与 volume provider 没有关系。 上面两点决定了 backup 具有容灾功能;而 snapshot 则提供 volume provider 内便捷的回溯功能。 配置 cinder-backup Cinder 的 backup 功能是由 cinder-backup 服务提供的,devstack 默认没有启用该服务,需要手工启用。与 cinder-volume 类似,cinder-backup 也通过 driver 架构支持多种备份 backend,包括 POSIX 文件系统、NFS、Ceph、GlusterFS、Swift 和 IBM TSM。支持的driver 源文件放在 /opt/stack/cinder/cinder/backup/drivers/ 本节我们将以 NFS 为 backend 来研究 backup 操作。 在实验环境中,存放 volume backup 的 NFS 远程目录为 192.168.104.11:/backup cinder-backup 服务节点上 mount point 为 /backup_mount。 需要在 /etc/cinder/cinder.conf 中作相应配置。 然后手工启动 cinder-backup 服务。 /usr/bin/python /usr/local/bin/cinder-backup --config-file /etc/cinder/cinder.conf 一切准备就绪,下面我们来看 backup 操作的流程 向 cinder-api 发送 backup 请求 cinder-api 发送消息 cinder-backup 执行 backup 操作 下面我们详细讨论每一个步骤。 向 cinder-api 发送 backup 请求 客户(可以是 OpenStack 最终用户,也可以是其他程序)向 cinder-api 发送请求:“请 backup 指定的 volume。 这里我们将 backup volume “vol-1”,目前 backup 只能在 CLI 中执行。 这里因为 vol-1 已经 attach 到 instance,需要使用 --force 选项。 cinder-api 接收到 backup volume 的请求。日志文件在 /opt/stack/logs/c-api.log。 cinder-api 发送消息 cinder-api 发送 backup 消息。cinder-api 没有打印发送消息的日志,只能通过源代码查看 /opt/stack/cinder/cinder/backup/api.py,方法为 create。 cinder-backup 执行 backup 操作 cinder-backup 收到消息后,通过如下步骤完成 backup 操作,日志为 /opt/stack/logs/c-vol.log。 启动 backup 操作,mount NFS。 创建 volume 的临时快照。 创建存放 backup 的 container 目录。 对临时快照数据进行压缩,并保存到 container 目录。 创建并保存 sha256(加密)文件和 metadata 文件。 删除临时快照。 Backup 完成后,我们可以查看一下 container 目录的内容 里面有三个文件,根据前面的日志我们可以知道: backup-00001,压缩后的 backup 文件。 backup_metadata,metadata 文件。 backup_sha256file,加密文件。 可以通过 cinder backup-list 查看当前存在的 backup。 另外我们可以查看一下 cinder backup-create 的用法。 这里有 --incremental 选项,表示可以执行增量备份。 如果之前做过普通(全量)备份,之后可以通过增量备份大大减少需要备份的数据量,是个很不错的功能。增量备份的操作和日志分析留给大家做练习。以上就是 volume backup 的分析,下一节我们讨论如何通过 restore 操作恢复备份的 volume。

优秀的个人博客,低调大师

Delete Volume 操作 - 每天5分钟玩转 OpenStack(57)

今天讨论 cinder 如何删除 volume 。 状态为 Available 的 volume 才能够被 delete。如果 volume 当前已经 attach 到 instance,需要先 detach 后才能 delete。 Delete操作实现比较简单,流程图如下: 向 cinder-api 发送 delete 请求 cinder-api 发送消息 cinder-volume 执行 delete 操作 下面我们详细讨论每一个步骤。 向 cinder-api 发送 delete 请求 客户(可以是 OpenStack 最终用户,也可以是其他程序)向 cinder-api 发送请求:“请 delete 指定的 volume。 这里我们将 delete volume “vol-2” 进入 GUI 操作菜单 Project -> Compute -> Volumes。 选择volume “vol-2”,点击“Delete Volume”。 再次确认。 cinder-api 将接收到 delete volume 的请求。日志文件在 /opt/stack/logs/c-api.log。 cinder-api 发送消息 cinder-api 发送消息 delete 消息。cinder-api 没有打印发送消息的日志,只能通过源代码查看 /opt/stack/cinder/cinder/volume/api.py,方法为 extend。 cinder-volume delete volume cinder-volume 执行 lvremove 命令 delete volume。 日志为 /opt/stack/logs/c-vol.log。 这里比较有意思的是:cinder-volume 执行的是“安全”删除。 所谓“安全”实际上就是将 volume 中的数据抹掉,LVM driver 使用的是 dd 操作将 LV 的数据清零。日志如下: 然后删除 LV。 以上就是 delete volume 的分析,下一节我们讨论 snapshot 操作。

优秀的个人博客,低调大师

Extend Volume 操作 - 每天5分钟玩转 OpenStack(56)

前面我们讨论了 volume 的 attach 和 detach 操作,今天讨论如何扩大 volume 的容量。为了保护现有数据,cinder 不允许缩小 volume。 Extend 操作用于扩大 Volume 的容量,状态为 Available 的 volume 才能够被 extend。如果 volume 当前已经 attach 给 instance,需要先 detach 后才能 extend。 Extend 实现比较简单,流程图如下: 向 cinder-api 发送 extend 请求 cinder-api 发送消息 cinder-volume 执行 extend 操作 下面我们详细讨论每一个步骤。 向 cinder-api 发送 extend 请求 客户(可以是 OpenStack 最终用户,也可以是其他程序)向 cinder-api 发送请求:“请 extend 指定的 volume。 这里我们将 extend volume “vol-2”。 进入 GUI 操作菜单 Project -> Compute -> Volumes。 vol-2 当前大小为 1GB。其在存储节点上对应的 LV 信息如下: 选择 volume “vol-2”,点击 “Extend Volume”。 指定新的容量为 3GB,点击 “Extend Volume”。 cinder-api 将接收到 extend volume 的请求。日志文件在 /opt/stack/logs/c-api.log。 cinder-api 发送消息 cinder-api 发送消息 extend 消息。cinder-api 没有打印发送消息的日志,只能通过源代码查看。/opt/stack/cinder/cinder/volume/api.py,方法为 extend。 cinder-volume extend volume cinder-volume 执行 lvextend 命令 extend volume。 日志为 /opt/stack/logs/c-vol.log LV 被 extend 到 3GB。 Extend 操作完成后,GUI 也会更新 volume 的状态信息。 以上就是 extend volume 的分析,下一节我们讨论 delete 操作。

优秀的个人博客,低调大师

Detach Volume 操作 - 每天5分钟玩转 OpenStack(55)

上一节我们成功地通过 attach 操作为 instance 添加了 volume,而与之相对的操作是 detach,就是将 volume 从 instance 上卸载下来。 下图是 Detach 操作的流程图 向 cinder-api 发送 detach 请求 cinder-api 发送消息 nova-compute detach volume cinder-volume 删除 target 下面我们详细讨论每一个步骤。 向 cinder-api 发送 attach 请求 客户(可以是 OpenStack 最终用户,也可以是其他程序)向 cinder-api 发送请求:“请 detach 指定 instance 上的 volume。 这里我们将 detach instance “c2”上的 volume “vol-1” 进入 GUI 操作菜单Project -> Compute -> Volumes。 选择 volume “vol-1”,点击“Manage Attachments”。 点击 “Detach Volume”。 再次确认。 cinder-api 将接收到 detach volume 的请求。日志文件在 /opt/stack/logs/c-api.log。 cinder-api 发送消息 cinder-api 发送消息 detach 消息。 cinder-api 没有打印发送消息的日志,只能通过源代码查看 /opt/stack/cinder/cinder/volume/api.py,方法为 detach。 Detach 的操作由 nova-compute 和 cinder-volume 共同完成: 首先 nova-compute 将 volume 从 instance 上 detach,然后断开与 iSCSI target 的连接。 最后 cinder-volume 删除 volume 相关的 iSCSI target。 后面两个小节将详细讨论这两个步骤。 nova-compute detach volume nova-compute 首先将 volume 从 instance 上 detach 。 日志为 /opt/stack/logs/n-cpu.log。 这时通过 virsh edit 可以看到 XML 配置文件中已经不在有 volume 的虚拟磁盘。 接下来断开与 iSCSI target 的连接。 具体有下面几个步骤: 将缓存中的数据 Flush 到 volume。 删除计算节点上 volume 对应的 SCSI 设备。 通过 iscsiadm 的 logout,delete 操作断开与 iSCSI target 的连接。 compue-nova 完成了 detach 工作,接下来 cinder-volume 就可以删除 volume 相关的 target 了。 cinder-volume 删除 target 存储节点 cinder-volume 通过 tgt-admin 命令删除 volume 对应的 target。日志文件为 /opt/stack/logs/c-vol.log。 至此 detach volume 操作已经完成,GUI 也会更新 volume 的 attach 信息。 以上就是 detach volume 的分析,下一节我们讨论 extend 操作。

优秀的个人博客,低调大师

Cinder 组件详解 - 每天5分钟玩转 OpenStack(47)

本节我们将详细讲解 Cinder 的各个子服务。 cinder-api cinder-api 是整个 Cinder 组件的门户,所有 cinder 的请求都首先由 nova-api 处理。cinder-api 向外界暴露若干 HTTP REST API 接口。在 keystone 中我们可以查询 cinder-api 的 endponits。 客户端可以将请求发送到 endponits 指定的地址,向 cinder-api 请求操作。 当然,作为最终用户的我们不会直接发送 Rest API 请求。OpenStack CLI,Dashboard 和其他需要跟 Cinder 交换的组件会使用这些 API。 cinder-api 对接收到的 HTTP API 请求会做如下处理: 检查客户端传人的参数是否合法有效 调用 cinder 其他子服务的处理客户端请求 将 cinder 其他子服务返回的结果序列号并返回给客户端 cinder-api 接受哪些请求呢?简单的说,只要是 Volume 生命周期相关的操作,cinder-api 都可以响应。大部分操作都可以在 Dashboard 上看到。 打开 Volume 管理界面 点击下拉箭头,列表中就是 cinder-api 可执行的操作。 cinder-scheduler 创建 Volume 时,cinder-scheduler 会基于容量、Volume Type 等条件选择出最合适的存储节点,然后让其创建 Volume。 这个部分比较多,我们下一次单独讨论。 cinder-volume cinder-volume 在存储节点上运行,OpenStack 对 Volume 的操作,最后都是交给 cinder-volume 来完成的。 cinder-volume 自身并不管理真正的存储设备,存储设备是由 volume provider 管理的。cinder-volume 与 volume provider 一起实现 volume 生命周期的管理。 通过 Driver 架构支持多种 Volume Provider 接着的问题是:现在市面上有这么多块存储产品和方案(volume provider),cinder-volume 如何与它们配合呢? 这就是我们之前讨论过的 Driver 架构。 cinder-volume 为这些 volume provider 定义了统一的接口,volume provider 只需要实现这些接口,就可以 Driver 的形式即插即用到 OpenStack 系统中。下面是 Cinder Driver 的架构示意图: 我们可以在 /opt/stack/cinder/cinder/volume/drivers/ 目录下查看到 OpenStack 源代码中已经自带了很多 volume provider 的 Driver: 存储节点在配置文件 /etc/cinder/cinder.conf 中用 volume_driver 选项配置使用的driver: 这里 LVM 是我们使用的 volume provider。 定期向 OpenStack 报告计算节点的状态 在前面 cinder-scheduler 会用到 CapacityFilter 和 CapacityWeigher,它们都是通过存储节点的空闲容量来做筛选。那这里有个问题:Cinder 是如何得知每个存储节点的空闲容量信息的呢? 答案就是:cinder-volume 会定期向 Cinder 报告。 从 cinder-volume 的日志 /opt/stack/logs/c-vol.log 可以发现每隔一段时间,cinder-volume 就会报告当前存储节点的资源使用情况。 因为在我们的实验环境中存储节点使用的是 LVM,所以在上面的日志看到存储节点通过“vgs”和”lvs”这两个命令获取 LVM 的容量使用信息。 实现 volume 生命周期管理 Cinder 对 volume 的生命周期的管理最终都是通过 cinder-volume 完成的,包括 volume 的 create、extend、attach、snapshot、delete 等,后面我们会详细讨论。 下一节我们将详细讨论 cinder-scheduler 如何筛选 cinder-volume。

优秀的个人博客,低调大师

Nova 组件详解 - 每天5分钟玩转 OpenStack(26)

本节开始,我们将详细讲解 Nova 的各个子服务。 前面架构概览一节知道 Nova 有若干 nova-* 的子服务,下面我们将依次学习最重要的几个。今天先讨论 nova-api 和 nova-conductor。 nova-api Nova-api 是整个 Nova 组件的门户,所有对 Nova 的请求都首先由 nova-api 处理。 Nova-api 向外界暴露若干 HTTP REST API 接口。 在 keystone 中我们可以查询 nova-api 的 endponits。 客户端就可以将请求发送到 endponits 指定的地址,向 nova-api 请求操作。 当然,作为最终用户的我们不会直接发送 Rest AP I请求。 OpenStack CLI,Dashboard 和其他需要跟 Nova 交换的组件会使用这些 API。 Nova-api 对接收到的 HTTP API 请求会做如下处理: 1. 检查客户端传人的参数是否合法有效 2. 调用 Nova 其他子服务的处理客户端 HTTP 请求 3. 格式化 Nova 其他子服务返回的结果并返回给客户端 nova-api 接收哪些请求? 简单的说,只要是跟虚拟机生命周期相关的操作,nova-api 都可以响应。 大部分操作都可以在 Dashboard 上找到。 打开Instance管理界面 点击下拉箭头,列表中就是 nova-api 可执行的操作。 OpenStack 用术语 “Instance” 来表示虚拟机,后面我们将统一使用这个术语。 nova-conductor nova-compute 需要获取和更新数据库中 instance 的信息。 但 nova-compute 并不会直接访问数据库,而是通过 nova-conductor 实现数据的访问。 这样做有两个显著好处: 更高的系统安全性 更好的系统伸缩性 更高的安全性 在 OpenStack 的早期版本中,nova-compute 可以直接访问数据库,但这样存在非常大的安全隐患。 因为 nova-compute 这个服务是部署在计算节点上的,为了能够访问控制节点上的数据库,就必须在计算节点的 /etc/nova/nova.conf 中配置访问数据库的连接信息,比如 [database] connection = mysql+pymysql://root:secret@controller/nova?charset=utf8 试想任意一个计算节点被黑客入侵,都会导致部署在控制节点上的数据库面临极大风险。 为了解决这个问题,从 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 的数量来应对日益增长的计算节点对数据库的访问。下一节我们讨论计算节点调度服务 nova-scheduler.

优秀的个人博客,低调大师

理解 Nova 架构 - 每天5分钟玩转 OpenStack(23)

Compute Service Nova 是 OpenStack 最核心的服务,负责维护和管理云环境的计算资源。 OpenStack 作为 IaaS 的云操作系统,虚拟机生命周期管理也就是通过 Nova 来实现的。 在上图中可以看到,Nova 处于 Openstak 架构的中心,其他组件都为 Nova 提供支持:Glance 为 VM 提供 image Cinder 和 Swift 分别为 VM 提供块存储和对象存储 Neutron 为 VM 提供网络连接 Nova 架构如下 Nova 的架构比较复杂,包含很多组件。 这些组件以子服务(后台 deamon 进程)的形式运行,可以分为以下几类: API nova-api接收和响应客户的 API 调用。 除了提供 OpenStack 自己的API,nova-api 还支持 Amazon EC2 API。 也就是说,如果客户以前使用 Amazon EC2,并且用 EC2 的 API 开发了些工具来管理虚机,那么如果现在要换成 OpenStack,这些工具可以无缝迁移到 OpenStack,因为 nova-api 兼容 EC2 API,无需做任何修改。 Compute Core nova-scheduler虚机调度服务,负责决定在哪个计算节点上运行虚机 nova-compute管理虚机的核心服务,通过调用 Hypervisor API 实现虚机生命周期管理 Hypervisor计算节点上跑的虚拟化管理程序,虚机管理最底层的程序。 不同虚拟化技术提供自己的 Hypervisor。 常用的 Hypervisor 有 KVM,Xen, VMWare 等 nova-conductornova-compute 经常需要更新数据库,比如更新虚机的状态。 出于安全性和伸缩性的考虑,nova-compute 并不会直接访问数据库,而是将这个任务委托给 nova-conductor,这个我们在后面会详细讨论。 Console Interface nova-console用户可以通过多种方式访问虚机的控制台: nova-novncproxy,基于 Web 浏览器的 VNC 访问 nova-spicehtml5proxy,基于 HTML5 浏览器的 SPICE 访问 nova-xvpnvncproxy,基于 Java 客户端的 VNC 访问 nova-consoleauth负责对访问虚机控制台请求提供 Token 认证 nova-cert提供 x509 证书支持 Database Nova 会有一些数据需要存放到数据库中,一般使用 MySQL。 数据库安装在控制节点上。 Nova 使用命名为 “nova” 的数据库。 Message Queue 在前面我们了解到 Nova 包含众多的子服务,这些子服务之间需要相互协调和通信。 为解耦各个子服务,Nova 通过 Message Queue 作为子服务的信息中转站。 所以在架构图上我们看到了子服务之间没有直接的连线,它们都通过 Message Queue 联系。 OpenStack 默认是用 RabbitMQ 作为 Message Queue。 MQ 是 OpenStack 的核心基础组件,我们后面也会详细介绍。下一节我们讨论这些 Nova 组件如何协调工作。

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

用户登录
用户注册