首页 文章 精选 留言 我的

精选列表

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

Neutron 架构 - 每天5分钟玩转 OpenStack（67）

前面我们讨论了 Neutron 的基本概念，今天我们开始分析 Neutron 的架构。 Neutron 架构 与 OpenStack 的其他服务的设计思路一样，Neutron 也是采用分布式架构，由多个组件（子服务）共同对外提供网络服务。 Neutron 由如下组件构成： Neutron Server对外提供 OpenStack 网络 API，接收请求，并调用 Plugin 处理请求。 Plugin处理 Neutron Server 发来的请求，维护 OpenStack 逻辑网络的状态， 并调用 Agent 处理请求。 Agent处理 Plugin 的请求，负责在 network provider 上真正实现各种网络功能。 network provider提供网络服务的虚拟或物理网络设备，例如 Linux Bridge，Open vSwitch 或者其他支持 Neutron 的物理交换机。 QueueNeutron Server，Plugin 和 Agent 之间通过 Messaging Queue 通信和调用。 Database存放 OpenStack 的网络状态信息，包括 Network, Subnet, Port, Router 等。 Neutron 架构非常灵活，层次较多，其目的是： 为了支持各种现有或者将来会出现的优秀网络技术。 支持分布式部署，获得足够的扩展性。 通常鱼和熊掌不能兼得，虽然获得了这些优势，但这样使得 Neutron 更加复杂，更不容易理解。 后面我们会详细讨论 Neutron 的各个组件，但在这之前，非常有必要先通过一个例子了解这些组件各自的职责以及是如何协同工作。 以创建一个 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 设备。 关于 linux bridge 如何实现 VLAN 大家可以参考本教程“预备知识->网络虚拟化”的相关章节。 这里进行几点说明： plugin 解决的是 What 的问题，即网络要配置成什么样子？而至于如何配置 How 的工作则交由 agent 完成。 plugin，agent 和 network provider 是配套使用的，比如上例中 network provider 是 linux bridge，那么就得使用 linux bridge 的 plungin 和 agent；如果 network provider 换成了 OVS 或者物理交换机，plugin 和 agent 也得替换。 plugin 的一个主要的职责是在数据库中维护 Neutron 网络的状态信息，这就造成一个问题：所有 network provider 的 plugin 都要编写一套非常类似的数据库访问代码。为了解决这个问题，Neutron 在 Havana 版本实现了一个 ML2（Modular Layer 2）plugin，对 plgin 的功能进行抽象和封装。有了 ML2 plugin，各种 network provider 无需开发自己的 plugin，只需要针对 ML2 开发相应的 driver 就可以了，工作量和难度都大大减少。ML2 会在后面详细讨论。 plugin 按照功能分为两类： core plugin 和 service plugin。core plugin 维护 Neutron 的 netowrk, subnet 和 port 相关资源的信息，与 core plugin 对应的 agent 包括 linux bridge, OVS 等； service plugin 提供 routing, firewall, load balance 等服务，也有相应的 agent。后面也会分别详细讨论。 以上是Neutron的逻辑架构，下一节我们讨论 Neutron 的物理部署方案。
2016-07-31
优秀的个人博客,低调大师

理解 Glance - 每天5分钟玩转 OpenStack（20）

OpenStack 由 Glance 提供 Image 服务。 理解 Image 要理解 Image Service 先得搞清楚什么是 Image 以及为什么要用 Image？ 在传统 IT 环境下，安装一个系统是要么从安装 CD 从头安装，要么用 Ghost 等克隆工具恢复。这两种方式有如下几个问题： 如果要安装的系统多了效率就很低 时间长，工作量大 安装完还要进行手工配置，比如安装其他的软件，设置 IP 等 备份和恢复系统不灵活 云环境下需要更高效的解决方案，这就是 Image。 Image 是一个模板，里面包含了基本的操作系统和其他的软件。 举例来说，有家公司需要为每位员工配置一套办公用的系统，一般需要一个 Win7 系统再加 MS office 软件。 OpenStack 是这么玩的： 先手工安装好这么一个虚机 然后对虚机执行 snapshot，这样就得到了一个 image 当有新员工入职需要办公环境时，立马启动一个或多个该 image 的 instance（虚机）就可以了 在这个过程中，第 1 步跟传统方式类似，需要手工操作和一定时间。但第 2、3 步非常快，全自动化，一般都是秒级别。 而且 2、3 步可以循环做。 比如公司新上了一套 OA 系统，每个员工的 PC 上都得有客户端软件。 那么可以在某个员工的虚机中手工安装好 OA 客户端，然后执行 snapshot ，得到新的 image，以后就直接使用新 image 创建虚机就可以了。 另外，snapshot 还有备份的作用，能够非常方便的恢复系统。 理解 Image Service Image Service 的功能是管理 Image，让用户能够发现、获取和保存 Image。 在 OpenStack 中，提供 Image Service 的是 Glance，其具体功能如下： 提供 REST API 让用户能够查询和获取 image 的元数据和 image 本身 支持多种方式存储 image，包括普通的文件系统、Swift、Amazon S3 等 对 Instance 执行 Snapshot 创建新的 image Glance 架构 上面是 Glance 的架构图 glance-api glance-api 是系统后台运行的服务进程。 对外提供 REST API，响应 image 查询、获取和存储的调用。 glance-api 不会真正处理请求。 如果是与 image metadata（元数据）相关的操作，glance-api 会把请求转发给 glance-registry； 如果是与 image 自身存取相关的操作，glance-api 会把请求转发给该 image 的 store backend。 在控制节点上可以查看 glance-api 进程 glance-registry glance-registry 是系统后台运行的服务进程。 负责处理和存取 image 的 metadata，例如 image 的大小和类型。 在控制节点上可以查看 glance-registry 进程 Glance 支持多种格式的 image，包括 Database Image 的 metadata 会保持到 database 中，默认是 MySQL。 在控制节点上可以查看 glance 的 database 信息 Store backend 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 中配置的在我们的 devstack 环境中，image 存放在控制节点本地目录 /opt/stack/data/glance/images/ 中 其他 backend 的配置可参考http://docs.openstack.org/liberty/config-reference/content/configuring-image-service-backends.html 查看目前已经存在的 image 查看保存目录 每个 image 在目录下都对应有一个文件，文件以 image 的 ID 命名。 下节我们来实际操作 Glance。
2016-04-12
优秀的个人博客,低调大师

OpenStack 架构 - 每天5分钟玩转 OpenStack（15）

终于正式进入 OpenStack 部分了。 今天开始，CloudMan 将带着大家一步一步揭开 OpenStack 的神秘面纱。 OpenStack 已经走过了 6 个年头。 每半年会发布一个版本，版本以字母顺序命名。现在已经到第 12 个版本 Liberty（字母 L）。 OpenStack最初只有两个模块（服务），现在已经有 20+（见下图），每个模块作为独立的子项目开发。 面对如此庞大的阵容，作为初学者我们如何起步呢？ 这也是 CloudMan 写这个系列教程的初衷： 通过实际操作帮助初学者由浅入深地学习和实践 OpenStack，并最终具备实施 OpenStack 的能力。 我们会把学习的重点放在 OpenStack 最核心的地方。 那什么是核心呢？请看下图 作为 IaaS 层的云操作系统，OpenStack 为虚拟机提供并管理三大类资源：计算、网络和存储。 这三个就是核心，所以我们的学习重点就是： 搞清楚 OpenStack 是如何对计算、网络和存储资源进行管理的。 在 20+ 模块中，管理这三类资源的核心模块其实不多，这几个模块就是我们的重点了。 要达到这个目的，我们自然需要研究 OpenStack 的整体架构。 架构里哪些核心模块负责管理计算资源、网络资源和存储资源？模块之间如何协调工作？ 同时我们会构建一个实验环境，进到各个模块的内部，通过实际操作真正理解和掌握 OpenStack。 好，下面我们就从架构开始吧。 OpenStack 架构 架构是个好东西，它能帮助我们站在高处看清楚事物的整体结构，避免过早地进入细节而迷失方向。 下图是 OpenStack 的 Conceptual Architecture 中间菱形是虚拟机，围绕 VM 的那些长方形代表 OpenStack 不同的模块（OpenStack 叫服务，后面都用服务这个术语），下面来分别介绍。 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。 在上面的这些服务中，哪些是 OpenStack 的核心服务呢？ 核心服务就是如果没有它，OpenStack 就跑不起来。 很显然 Nova 管理计算资源，是核心服务。 Neutron 管理网络资源，是核心服务。 Glance 为 VM 提供 OS 镜像，属于存储范畴，是核心服务。 Cinder 提供块存储，VM怎么也得需要数据盘吧，是核心服务。 Swift 提供对象存储，不是必须的，是可选服务。 Keystone 认证服务，没它 OpenStack 转不起来，是核心服务。 Ceilometer 监控服务，不是必须的，可选服务。 Horizon 大家都需要一个操作界面吧。 现在核心服务有了，接下来我们将镜头拉近点，看看核心服务内部的组成结构。 Logical Architecture 在 Logical Architecture 中，可以看到每个服务又由若干组件组成。 以 Neutron 为例，包含 Neutron Server、Neutron plugins 和 Neutron agents Network provider 消息队列 Queue 数据库 Neutron Database 在后面 Neutron 章节我们会展开学习这些组件。 这里想要强调一点： 上面是 Logical Architecture，描述的是 Neutron 服务各个组成部分以及各组件之间的逻辑关系。 而在实际的部署方案上，各个组件可以部署到不同的物理节点上。 OpenStack 本身是一个分布式系统，不但各个服务可以分布部署，服务中的组件也可以分布部署。 这种分布式特性让 OpenStack 具备极大的灵活性、伸缩性和高可用性。 当然从另一个角度讲，这也使得 OpenStack 比一般系统复杂，学习难度也更大。 后面章节我们会深入学习 Keystone、Glance、Nova、Neutron 和 Cinder 这几个 OpenStack 最重要最核心的服务。
2016-03-31
优秀的个人博客,低调大师

功能对比表

腾讯云边缘安全加速平台 EO （Tencent Cloud EdgeOne，下文简称为 EdgeOne）是腾讯云 CDN 的全面升级产品，可提供更加丰富的功能、更灵活的配置方式以及更简便的上手方式，EdgeOne 相比 CDN，除了覆盖原 CDN 加速能力，还提供了安全防护、边缘函数、媒体即时处理、四层代理、DNS 解析等能力，通过一站式服务解决游戏、电商、视频、零售、金融等行业中存在的用户访问质量差、访问不稳定、攻击风险高等问题。
2026-08-22

资源下载

更多资源
Nacos

Nacos

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

时间: 2026-09-24 大小: 189MB 下载: 9次
Spring

Spring

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

时间: 2026-08-21 大小: 5MB 下载: 2次
Rocky Linux

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

时间: 2026-08-21 大小: 1.42GB 下载: 6次
WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源，继承了IntelliJ IDEA强大的JS部分的功能。

时间: 2025-12-13 大小: 249.54MB 下载: 22次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册