精华内容
下载资源
问答
  • openstack组件
    千次阅读
    2021-12-09 15:47:56

    1)keystone:身份认证与授权服务

    keystone是openstack的身份认证与授权服务;

    keystone负责对用户进行身份认证,并向被认定为合法的用户发放令牌(token)。用户持keystone发放的令牌访问openstack的其他项目,以使用其提供的服务。而各个组件中内嵌的令牌校验和权限控制机制,将于keystone配合实现对用户身份的识别和权限级别的控制,保证只有恰当的用用户才能能够对恰当的资源实施恰当的操作,以保证对不同用户资源的隔离与保护。


    2)nova:计算服务

    nova是openstack中负责提供此类计算服务的项目;

    向用户按需提供不同规格的虚拟机,是任何一个云操作系统最为基础的功能,nova的核心功能,是将大量部署了计算虚拟化软件(Hypervisor虚拟机监视器)的物理服务器统一纳入管理之下,组成一个具有完整资源视图的逻辑的资源池,在此基础上,nova通过接收不同用户发起的请求,对资源池中的资源进行生命周期管理操作。其中最核心的,就是虚拟机的创建、删除、启动、停止等操作。通过在执行客户发起的虚拟机创建操作,nova将逻辑资源池中的cpu、内存、本地存储、IO设备等资源,组装成不同规格的虚拟机,再安装上不同类型的操作系统,最终提供给用户进行使用,由此满足用户对于计算资源的需求。


    3)Glance:镜像服务

    Glance是openstack中镜像管理服务项目;(华为云服务:IMS)

    通常而言,在虚拟机被创建之后,都需要为其安装一个操作系统,以便用户使用。为此,云计算系统中往往需要预置若干不同种类、不同版本的操作系统镜像,以便用户选用。此外,在一些应用场景下,为进一步方便用户,镜像中还想需要预装一些常用的应用软件,这将进一步增加镜像的种类与数量。为此,云操作系统必须具备镜像管理服务能力。Glance主要负责对系统中提供的各类镜像的元数据进行管理,并提供镜像的创建、删除、查询、上传、下载等能力。但在正常的生产环境下,Glance本身并不直接负责镜像文件的存储,而是负责保管镜像的元数据,本质上是一个管理前端,Glance需要与真正的对象存储后端对接,才能共同提供完整的镜像管理与存储服务能力。


    4)Swift:对象存储服务

    Swift是openstack中用于提供对象存储服务的项目;(华为云服务:OBS)

    对象存储服务是云计算领域中一种常见的数据存储服务,通常与存储单文件数据量较大,访问不甚频繁、对数据访问延迟要求不高、对数据存储较为敏感的场景。Swift本身实现了完整的对象存储系统功能,甚至可以独立于openstack,被单独作为一个对象存储系统加以应用。在openstack中,Swift也可以作为Glance的后端存储,负责存储镜像文件。


    5)Cinder:块存储服务

    Cinder是openstack中提供的块存储服务,也成为卷服务;(华为云服务:EVS)

    在典型的、基于KVM虚拟化技术的openstack部署方案下,Nova创建的虚拟机默认使用各个计算节点的本地文件系统作为数据存储。这种数据存储的生命周期与虚拟机本身的生命周期相同,即当需虚拟机被删除时,数据存储也随之被删除。如果用户希望获得生命周期独立于虚拟机自身的、能持久存在的块存储介质,则需要使用Cinder提供的块存储服务。cinder负责将不同的后端存储设备或软件定义存储集群提供的存储能力,统一抽象为块存储资源池,然后根据不同需求划分为大小各异的卷,分配给用户使用。


    6)Neutron:网络服务

    Neutron是openstack中的网络服务项目

    网络服务,是任意云操作系统IaaS层能力的关键组成部分。只有基于稳定、易用、高性能的云上虚拟网络,用户才能将云计算系统提供的各类资源和服务能力连接成真正满足需求的应用系统,以解决自身的实际业务需求。Neutron及其自身孵化出来的一系列子项目,共为用户提供了从Layer2 到 Layer 7上不同层次的多种网络服务功能,包括Layer2组网(network、subnet、port)、Layer3组网、内网DHCP管理、Internet浮动IP管理、内网防火墙、负载均衡、VPN、LB等。


    7)Heat:资源编配服务

    Heat是openstack中提供自动化应用系统生命周期管理能力

    云计算的核心价值之一,在于IT资源于服务管理和使用的自动化。用户业务应用系统的生命周期管理操作,即应用系统的安装、配置、扩容、撤除等,可谓是具有代表性的一类。这类操作复杂耗时耗力,Heat能解析用户提交的,描述应用系统对资源类型、数量、连接关系要求的定义模板,并根据模板要求,调用Nova、Cinder、Neutron等项目提供的API,自动实现应用系统的部署工作。


    8)Ceilometer:监控与计量

    Ceilometer是openstack中负责资源用量监控和计量能力

    在云计算系统中,各类资源均以服务化的形式向用户提供,用户也需要按照所使用资源的类型和数量缴费。核心功能是以轮询的方式,收集不同用户所使用的资源类型与数量信息,以此作为计费的依据。在此基础上,Ceilometer可以利用收集的信息,通过Aodh 子项目发送告警信号,触发Heat项目执行弹性伸缩功能。需要说明的是,Ceilometer项目自身并不提供计费能力。系统设计者需要将其与适当的计费模块相对接,才能实现完整的用户计费功能。

    9)Horizon:图形界面

    Horizon项目是openstack社区提供的图形化人机界面

    Horizon界面简洁美观,功能丰富易用,Horizor的架构高度插件化,灵活而易于扩展。

    更多相关内容
  • Keystone安装列表Openstack组件部署—Overview和前期环境准备Openstack组建部署—EnvironmentofControllerNodeOpenstack组件部署—Keystone功能介绍与认证实现流程Openstack组件部署—KeystoneInstall&...
  • Openstack组件卸载命令

    2015-10-07 17:24:40
    Openstack组件卸载命令,跟上面的Openstack实验相对应的卸载文档。http://download.csdn.net/detail/u014028392/9161039
  • openstack组件详解

    2021-05-10 16:14:42
    openstack包换了许多组件。有些组件会首先出现在孵化项目中,待成熟以后进入下一个openstack发行版的核心服务中。同时也有部分项目是为了更好的支持openstack社区和项目开发管理,不包含在发行版代码中。 Openstak...

    Opestack的结构

    openstack包换了许多组件。有些组件会首先出现在孵化项目中,待成熟以后进入下一个openstack发行版的核心服务中。同时也有部分项目是为了更好的支持openstack社区和项目开发管理,不包含在发行版代码中。

    Openstak核心服务包括:
    1,Nova计算服务(Compute as a Service)
    2,Neutron网络服务(Networking as a Service )
    3,Swift对象存储服务(Object Storage as a Service)
    4,Cinder块存储服务(Block Storage as a Service)
    Openstack公共服务包括:
    1,Glance镜像服务(Image as a Service)
    2,Keystone认证服务(Identity as a Service)
    3,Horizon仪表盘服务(Dashboard as a Service)
    Openstack的依赖库项目包括:Oslo基础设施代码共享依赖库(CommonLab as a Service)
    Openstack的孵化项目包括
    1,Celiometer 计费&监控服务
    2,Heat 编排服务
    3,Ironic 物理设备服务(Bare Metal as a Service)
    4,Marconi消息队列服务(Message Queue as a Service)
    5,Savanna 大数据处理(MapReduce as a Service)
    6,Trove数据库服务(Database as a Service)
    Openstack的其他服务

    keystone

    这是提供身份认证和授权的组件。任何系统,身份认证和授权,其实都比较复杂。尤其Openstack 那么庞大的项目,每个组件都需要使用统一认证和授权。
    目前keystone 要做的东西其实还是很多。没法基于角色的授权,web管理用户等。

    Nova OpenStackCompute

    Nova是最核心的,可以说是一套虚拟化管理程序,因为nova可以创建、删除虚拟机、重启虚拟机等,openstack的之所以能够搭建云平台,也是因为它能够创建虚拟机,其它的组件,比如Neutron则是为了让虚拟机之间、虚拟机与外网之间能够互通,Cinder则是为了增加虚拟机的存储空间。可见nova在openstack中作用是非常大的

    Dashboard

    (代号为“Horizon”) 为所有OpenStack的服务提供了一个模块化的web-based用户界面。使用这个Web GUI,可以在云上完成大多数的操作,如启动实例,分配IP地址,设置访问控制等

    Glance

    这是镜像管理。
    目前Glance的镜像存储,支持本地存储,NFS,swift,sheepdog和Ceph,基本是够用了。
    目前Glance的最大需求就是多个数据中心的镜像管理,如何复制,不过这个功能已经基本实现。还有就是租户私有的image管理,这些目前功能都已经实现。

    Neutron

    这是网络管理的组件,也是重头戏,Openstack的未来,基本都要靠quantum。网络相关的内容,都会交给Quantum。不过Quantum的开发进度不是太如人意。Flosom规划实现功能,到Grizzly才实现。未来nova network的代码清理,估计到H版本都不见得可以实现。Quantum 后端可以是商业产品或者开源。开源产品支持Openvswitch,和linux bridge。网络设备厂商都在积极参与,让他们的产品支持Quantum。
    网络组件nova-network的发展经历了nova-network->Quantum->Neutron,Openstack在2010年正式发布它的第一个版本Austin的时候,nova-network作为它的核心组件被包含其中,网络由nova-network来承担,后来逐渐分离出来,改名为Quantum. Quantum是随Openstack的Folsom版本正式发布的,其实它已经作为试用组件包含在之前的Essex版本中。在Grizzly里功能得到了增强。
    Neutron
    因为商标侵权原因,Openstack在Havana版本将Quantum更名为Neutron,所以Neutron并不是什么新东西。在Havana版里,Neutron也只增加和增强了少数功能

    Cinder

    这是存储管理的组件。Cinder存储管理主要是指虚拟机的存储管理

    Swift

    这是对象存储的组件。对于大部分用户来说,swift不是必须的。你只有存储数量到一定级别,而且是非结构化数据才有这样的需求。很多人都问一个相同的问题:是否可以把虚拟机的存储放在swift上。简单回答:不行。你需要搞明白对象存储是干啥,擅长那些地方,那些是不行的。
    swift是Openstack所有组件了最成熟的,可以在线升级版本,各种版本可以混合在一起,也就是说,1.75版本的swift可以和1.48的在一个群集里.这个是很难得的.

    Ceilometer

    提供用量统计服务,通过它可以方便地实现 OpenStack 计费功能。

    Heat

    整合了 OpenStack 中的众多组件,类似 AWS 的 CloudFormation,让用户能够通过模板来管理资源

    用户身份管理有三个主要的概念:
    • 用户Users
    • 租户Tenants
    • 角色Roles

    1. 定义
      这三个概念的openstack官网定义(点击打开链接)
      1.1 用户(User)
      openstack官网定义User为“In OpenStack Identity, entities represent individual API consumers and are owned by a specific domain. In OpenStack Compute, a user can be associated with roles, projects, or both”
      关于用户需要明白以下:
    1. 一个用户就是一个有身份验证信息的API消费实体;
      2)一个用户可以属于多个租户/项目/组织, 角色;
      1.2 租户(Tenant)
      openstack官网定义Tenant为"A group of users; used to isolate access to Compute resources. An alternative term for a project”
      关于租户需要明白以下几点:
      1)【修改前】租户相当于一个用户组,包含多个用户。
      **注[updated on 2016/07/25]:以上这句话不是很准确,经核实后修改如下。
      1)【修改后】租户也可以理解为一个项目(Project)。 在API 3之前的版本,使用tenant, API 3之后的版本,更多的使用project。目前的openstack版本(Mitaka (April 2016))中,更多的使用的是peoject(项目)这个词,而不倾向于使用tenatn(租户)。Tenant其实是各个服务中的一些可以访问的资源集合。这些资源集合可供多个用户使用,这也是为什么用户默认的总是绑定到某些tenant上。
      2)用户通过租户访问计算管理资源(这里的计算管理资源可以理解为openstack服务),也就是说必须指定一个相应的租户才可以申请openstack服务。
    2. 各租户相互独立,在当前租户下无法查看其他租户信息。
      1.3 角色(Role)
      openstack官网定义role为“A personality that a user assumes to perform a specific set of operations. A role includes a set of rights and privileges. A user assuming that role inherits those rights and privileges.”
      关于角色需要明白以下:
      1)角色是可执行一特定系列操作的用户特性,角色规定了用户在某个租户中的一系列权利和特权。
      2)一般默认有超级管理员权限admin和普通管理员权限member。
    1. 举例

    以公司某员工需要向公司财务部门申请出差费用报销为例,说明三者关系。
    用户代表员工1, 他持有相关的信息,例如姓名、工号、电子邮箱等。 项目组属于不同的租户。用户1可以同时属于不同的几个项目组
    。当员工1提出申请出差补贴的请求时,必须指定一个他所属的项目组。而角色则规定了该员工在某一个项目组所拥有的权限,比如什么费用可以报销,什么不可以报销**

    展开全文
  • 本节教大家更新 OpenStack 组件的方法。请注意,是更新(Update)而不是升级(Upgrade)。更新是给组件打补丁,版本不变;而升级是刷新版本,比如从 kilo 升级到 liberty。 更新真的有必要吗? 对于已经部署好的 ...
  • OpenStack组件之Neutron

    2021-09-25 17:21:44
    1.Linux网络虚拟化基础 物理网络与虚拟化网络 Neutron最为核心的工作是对二层物理...Neutron为整个 Openstack环境提供网络支持,包括二层交换,三层路由,负载均衡,防火墙和VPN等。 Neutron提供了一个灵活的框

    1.Linux网络虚拟化基础

    物理网络与虚拟化网络

    Neutron最为核心的工作是对二层物理网络的抽象与管理,物理服务器虚拟化后,虚拟机的网络功能由虚拟网卡(vNIC)提供,物理交换机(Switch)也被虚拟化为虚拟交换机(vSwitch),各个vNIC连接在vSwitch的端口上,最后这些vSwitch通过物理服务器的物理网卡访问外部的物理网络。

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

    1.1-Linux网络虚拟化实现技术

    ①网卡虚拟化

    • TAP
    • TUN
    • VETH

    交换机虚拟化

    • Linux Bridge
    • Open vSwitch

    网络隔离

    • Network
    • Namespac

    1.2-Linux网卡虚拟化-TAP/TUN/VETH

    • TAP设备:模拟一个二层的网络设备,可以接收和发送二层网包
    • TUN设备:模拟一个三层的网络设备,可以接收和发送三层网包
    • VETH:虚拟Ethernet接口,通常以api的方式出现,一端发出的网包,会被另一端接收,可以形成两个网桥之间的通道。
    • TAP/TUN提供了一台主机内用户空间的数据传输机制,它虚拟了一套网络接口,这套接口和物理的接口无任何区别,可以配置 IP,可以路由流量,不同的是,它的流量只在主机内流通。
    • TAP/TUN 有些许的不同,TUN 只操作三层的 IP 包,而 TAP 操作二层的以太网帧。
    •  Veth-Pair 是成对出现的一种虚拟网络设备,一端连接着协议栈,一端连接着彼此,数据从一端出,从另一端进。它的这个特性常常用来连接不同的虚拟网络组件,构建大规模的虚拟网络拓扑,比如连接 Linux Bridge、OVS、LXC 容器等。一个很常见的案例就是它被用于 OpenStack Neutron,构建非常复杂的网络形态。

    1.3-交换机虚拟化——Linux bridge

    • Linux bridge:工作于二层的网络设备,功能类似于物理交换机
    • Bridge可以帮绑定Linux上的其他网络设备,并将这些设备虚拟化为端口。
    • 当一个设备被绑定到bridge时,就相当于物理交换机端口插入了一条连接着终端的网线。
    • 使用brctl命令配置Linux bridge:
    • Brctl addbr BRIDGE
    • Brctl addif BRIDGE DEVICE

    1.4-Linux交换机虚拟化-Open vSwitch

    •  Open vswitch是产品级的虚拟交换机
    • Linux bridge更适用于小规模,主机内部间通信场景。
    • Open vswitch更适合于大规模,多主机通信场景。

    1.5-Linux网络隔离-network namespace

    • Network namespace能创建多个隔离的网络空间,他们有独自的网络配置信息,例如网络设备、路由表、iptables等。
    • 不同网络空间中的虚拟机运行的时候仿佛自己就在独立的网络中。
    • Network Namespace通常与VRF(Virtual Routing Forwarding虚拟路由和转发)一起工作,VRF是一种IP技术,允许路由表的多个实例同时在同一路由器上共存。
    • 使用VETH可以连接两个不同网络命名空间,使用Bridge可以连接多个不同网络命名空间。

    2.Neutron概念

    • neutron负责管理虚拟网络组件,专注于为OpenStack提供网络即服务(NaaS);为OpenStack计算提供网络连通和寻址服务。

    2.1neutron功能

     1. 二层交换

           Neutron支持多种虚拟交换机,一般使用Linux Bridge和Open vSwitch创建传统的VLAN网络,以及基于隧道技术的Overlay网络,如VxLAN和GRE(Linux Bridge 目前只支持 VxLAN)。

      2. 三层路由

           Neutron从Juno版开始正式加入的DVR(Distributed Virtual Router)服务,它将原本集中在网络节点的部分服务分散到了计算节点上。可以通过namespace中使用ip route或者iptables实现路由或NAT,也可以通过openflow给OpenvSwitch下发流表来实现。

      3. 负载均衡

           LBaaS 支持多种负载均衡产品和方案,不同的实现以 Plugin 的形式集成到 Neutron,通过HAProxy来实现。

    4. 防火墙

            Neutron有两种方式来保障instance和网络的安全性,分别是安全组以及防火墙功能,均可以通过iptables来实现,前者是限制进出instance的网络包,后者是进出虚拟路由器的网络包。

    • 为了便于操作管理,neutron对网络进行了抽象,有如下基本管理对象:
    • Network
    • Subnet
    • Port
    • Router
    • Floating IP

    1.network

    • 网络;一个隔离的、虚拟二层广播域,可以看成一个虚拟交换机或者逻辑交换机。neutron支持多种类型的network,包括local、flat、VLAN、VXLAN和GRE
    • Local:与其他网络和节点隔离。Local 网络中的虚拟机只能与位于同一节点上同一网络的 虚拟机通信,Local 网络主要用于单机测试。 本地网络,只能在同一台compute主机上的VM通信
    • Flat:无VLAN tagging的网络。Flat网络中虚拟机能与位于同一网络的虚拟机通信,并可 以跨多个节点。VM可以在多台compute主机间通讯,不同子网可以通过路由
    • VLAN:802.1q tagging网络。VLAN是一个二层的广播域,同一VLAN中的 虚拟机可以通 信,不同VLAN只能通过Router通信。 VLAN网络可跨节点,是应用最广泛的网络类型。
    •  VXLAN:基于隧道技术的overlay网络。 VXLAN网络通过唯一的segmentation ID(也叫 VNI)与其他 VXLAN网络区分。 VXLAN中数据包会通过VNI封装成UDP包进行传输。因 为二层的包通过封装在三层传输,能够克服 VLAN 和物理网络基础设施的限制。
    •  GRE:与VXLAN类似的一种overlay网络,主要区别在于使用IP包而非UDP进行封装。
    •  生产环境中,一般使用的是VLAN、VXLAN或GRE网络。

    2.subnet

    子网;一个IPV4或者IPV6地址段。虚拟机的IP从subnet中分配。每个subnet需要定义IP地址的范围和掩码。subnet必须与network关联,subnet可选属性:DNS,网关IP,静态路由

    3.port

    端口;逻辑网络交换机上的虚拟交换端口,虚拟机通过port附着到network上,当instance上的虚拟网卡VIF(virtual interface)绑定到port时,port可以分配IP地址和Mac地址。

    4.router

    路由器;连接租户内同一network或不同network之间的子网,以及连接内外网。

    5.fixed IP

    固定IP;分配到每个端口上的IP,类似于物理环境中配置到网卡上的IP。

    6.floating IP

    浮动IP;floating IP是从external network创建的一种特殊port,可以将floating IP绑定到任意network中的port上,底层会做NAT转发,将发送给floating IP的流量转发到该port对应的fixed IP上。外界可以通过floating IP访问虚拟机,虚拟机也可以通过floating IP访问外界。

    7.physical network

    物理网络;在物理网络环境中连接openstack不同节点的网络,每个物理网络可以支持neutron中的一个或多个虚拟网络。

    openstack必须通过physical network才能和真实物理网络通信。

    8.provider network

    由openstack管理员创建的,直接对应于数据中心现有物理网络的一个网段。Provider network通常使用VLAN或者Flat模式,可以在多个租户之间共享。

    9.self- service network

    自助网络服务\租户网络\项目网络;由openstack租户创建的,完全虚拟的,只在本网络内部连通,不能再租户之间共享。

    • 通常使用VXLAN或者GRE模式,可以通过virtual router的SNAT与provider network通信。
    • 不同Self-service Network中的网段可以相同,类似于物理环境中不同公司的内部网络。 Self-service Network如果需要和外部物理网络通信,需要通过Router,类似于物理环境中公司上网需要通过路由器或防火墙。

    10.external network

    外部网络\公共网络;一种特殊的provider network,连接的物理网络与数据中心或internal相通,网络中的port可以访问外网。

    • 一般将租户的virtual router连接到该网络,并创建floating IP绑定该虚拟机,实现虚拟机与外网通信。
    • External Network类似于物理环境中直接使用公网IP网段,不同的是,OpenStack中External Network对应的物理网络不一 定能直连Internet,有可能只是数据中心的一个内部私有网络。

    11.security group

    安全组;安全组是作用在neutron port上的一组策略,规定了虚拟机入口和出口流量的规则;安全组基于Linux IPtables(包过滤防火墙)实现。安全组默认拒绝所有流量,只有添加了放行规则的流量才能通过。每个openstack项目中都有一个default默认安全组,默认包含如下规则:拒绝所有入口流量,允许所有出口流量。安全组由L2 agent实现,如neutron-openvswitch-agent会将安全组规则转换成IPTables规则,一般发生在计算节点;

    3.neutron架构图

    • Neutron Server

    对外提供 Openstack网络APl,接收请求,并调用 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

    Database 用来存放 Openstack的网络状态信息,包括 Network、 Subnet、Port、 Router等。

    Neutron 架构原则

     统一API

     核心部分最小化

    可插入式的开放架构

    可扩展

    Message Queue

      Neutron-server使用Message Queue与其他Neutron agents进行交换消息,但是这个 Message Queue不会用于Neutron-server与其他OpenStack组件(如nova )进行交换 消息。

     L2 Agent

      负责连接端口(ports)和设备,使他们处于共享的广播域(broadcast domain)。通常运 行在Hypervisor上。利用OVS、Linux的Bridge或者其他厂商的技术给每个project提供独立的网络服务。

     L3 Agent   (L3 Agent安装在哪里,哪里就是网络节点)

     负责连接tenant网络到数据中心,或连接到Internet。在真实的部署环境中,一般都需要 多个L3 Agent同时运行。

     DHCP agent

      用于自动配置虚拟机网络。

     Advanced Service

     提供LB、Firewall和VPN等服务

    • 通常,neutron-server部署在控制节点上,每个计算节点上都需要部署L2 Agent,L3 Agent一般运行在网络节点上,DHCP agent一般也部署在网络节点上;控制节点和网络节点是可以合并的, Neutron-server安装在哪里,哪里就是控制节点,L3 Agent安装在哪里,哪里就是网络节点,计算节点上一般只部署 L2 Agent

    4.neutron架构说明

    neutron的架构是基于插件的,不同的插件提供不同的网络服务,主要包含以下网络组件:

    • Neutron server

    对外提供网络API,并调用Plugi处理请求

    Core api:基础组件组成,对外提供管理网络、子网和端口的RESTful API;service api:高级组件组成,对外提供管理路由、防火墙、VPN等资源的RESTful API.

    • Plugin

    处理neutron server的请求,维护网络状态,并调用Agent处理请求

    • Agent

    处理Plugin的请求,调用底层虚拟或物理网络设备实现各种网络功能

    plugin、agent和network provider是配套使用的,如果network provider是Linux bridge,那么就得使用Linux bridge的plugin和agent,如果network provider换成了OVS或物理交换机,plugin和agent也得换

    5.neutron组件

     5.1-neutron server

    Neutron server=APIs+Plugins,通过这种方式,可以自由对接不同网络后端能力。

    • API定义各类网络服务
    • Plugin实现各类网络服务

    5.2-core Plugin

    主要指ML2 plugin(Modular Layer 2),是一个开放性框架,在一个plugin下,可以集成各个厂家、各种后端技术支持的Layer 2网络服务。

    • 通过Type Driver和Mechanism Driver调用不同的底层网络技术,实现二层互通
    • ML2 Plugin的Drivers主要分为以下两种:

      Type Driver:定义了网络类型,每种网络类型对应一个Type Driver。

     Mechanism Driver:对接各种二层网络技术和物理交换设备,如OVS,Linux Bridge等。Mechanism Driver从Type Driver获取相关的底层网络信息,确保对应 的底层技术能够根据这些信息正确配置二层网络。

     ML2 不但支持异构部署方案,同时能够与现有的Agent无缝集成:以前用的Agent不需要变,只需要将Neutron Server上的传统Core Plugin替换为ML2。有了ML2,要支持新的Network Provider就变得简单多了:无需从头开发Core Plugin,只需要开发相应的Mechanism Driver,大大减少了要编写和维护的代码。

    5.3-service plugin

    用于实现高阶网络服务,例如路由、负载均衡、防火墙和VPN服务等。L3 Service Plugin主要提供路由,浮动IP服务等。

    5.4-Agent

    向虚拟机提供二层和三层的网络连接、完成虚拟网络和物理网络之间的转换、提供扩展服务等

    一套OpenStack中,只能使用一种交换模式。ML2 Plugin可以兼容底层两种交换模式,比如用一个ML2 Plugin统一管理一个Linux  bridge,一个OVS

    拓扑

    一般compute节点有两个网卡,一个管理口,一个业务口,network节点有三个网卡,一个管理口,一个内部通讯网络(做路由的),一个与外部网络连接的网卡;

    br-int用来提供内部网络通信;br-ex提供内外网互通;br-tun是隧道网络,只用于VXLAN(跨数据中心的的大二层技术【将二层网络封装在三层中进行传输】) GRE网络

    不同租户的网络可以重叠吗?可以

    同一个物理交换机是如何隔离不同租户的?namespace命名空间,一个租户一个namespace

    veth是成对出现的(相当于一条网线连两台电脑),tap设备只有一个(相当于一张网卡)

    flat网络

    VM1和VM2通信,走它内部br-int的桥就通了;VM1访问VM3,通过br-eth1(虚拟交换机)连接物理网络就能通

    小结:

    neutron架构:

    Neutron server接收api请求

    Plugin/agent实现请求

    database保存neutron网络状态

    Message queue实现组件之间通信

    instance在启动之前需要访问nova-metadata-api服务获取metadata和userdata,这些data是该instance的定制化信息,比如hostname、ip、public key等。但instance启动时并没有ip,如何能够通过网络访问到nova- metadata-api服务呢?答案就是 neutron- metadata- agent。该 agent让 Instance能够通过dhcp- agent或者

    L3- agent与nova- metadata-api通信。

    L3基础概念

    L3即vrouter,主要功能是连接租户内同一network或不同network之间的子网,以及连接内外网(FIP/SNAT)。前者是数据中心内部虚机之前的通信,成为东西向流量。后者是虚机与外部通信,称为南北向流量。

    vrouter分为两种模式:集中式,分布式。集中式指的是vrouter实例化在network节点,compute节点不实例化vrouter,当两个不同子网的vm通信时,流量需要在network节点上的vrouter做一次三层转发,走两次隧道。分布式指的是vruoter实例化在所有compute节点,三层转发的功能在本节点的vrouter实例中完成。从而只需要走一次隧道。

    集中式路由

    1.之和网络节点有关系,router所在节点即为网络节点,只有在网络节点上部署L3-agent,实现3层通信的功能。

    2.所有3层流量必须经过网络节点

    分布式路由

    浮动IP

    NAT:将私有地址和公有地址进行一个转换,可以解决IP地址不足的问题,还能避免来自外网的攻击,隐藏和保护内部虚拟机。

    浮动IP:利用NAT原理给虚拟机配置一个外网IP,虚拟机访问外网时将原地址转换成该外网IP,外网访问该外网IP时转换成虚拟机IP实现通信

    展开全文
  • 本篇文章主要介绍了详解Openstack组件部署 — Overview和前期环境准备,具有一定的参考价值,感兴趣的小伙伴们可以参考一下。
  • 当前的重点是让基本组件工作并使用服务发现。 使用: 开发环境 启动 Vagrant 并为 Dockenstack 加载舰队单元。 $ vagrant up $ vagrant ssh core-01 $ fleetctl submit share/fleet/units/* 启动我们的支持容器并...
  • 中文描述openstack组件之间的关系,帮助理解openstack架构
  • 这里写目录标题前言一、...nova和swift是openstack最早的两个组件,nova分为控制节点和计算节点,计算节点通过nova computer进行虚拟机创建,通过libvirt调用kvm创建虚拟机,nova之间通信通过rabbitMQ队列进行通信 一

    前言

    nova和swift是openstack最早的两个组件,nova分为控制节点和计算节点,计算节点通过nova computer进行虚拟机创建,通过libvirt调用kvm创建虚拟机,nova之间通信通过rabbitMQ队列进行通信

    一、Nova概述

    1.1 nova定义

    Nova(OpenStack Compute Service)是 OpenStack 最核心的服务,负责维护和管理云环境的计算资源,同时管理虚拟机生命周期。

    1.2、系统架构图介绍

    在这里插入图片描述

    • DB:用于数据存储的sql数据库。
    • API:用于接收HTTP请求、转换命令、通过消息队列或HTTP与其他组件通信的nova组件。
    • Scheduler:用于决定哪台计算节点承载计算实例的nova调度器。
    • Network:管理IP转发、网桥或虚拟局域网的nova网络组件。
    • Compute:管理虚拟机管理器与虚拟机之间通信的nova计算组件。
    • Conductor:处理需要协调(构建虚拟机或调整虚拟机大小)的请求,或者处理对象转换

    二、nova内部组件的介绍

    2.1、nova-api

    • AsPI是客户访问nova的http接口,它由nova-api服务实现,nova-api服务接受和响应来自最终用户计算api的请求。作为openstack对外服务的最主要接口,nova-api提供了一个集中的可以查询所有api的端点。

    • 所有对nova的请求都首先由nova-api处理。API提供REST 标准调用服务,便于与第三方系统集成。

    • 最终用户不会直接该送RESTful API请求而是通过openstack命令行、dashbord和其他需要跟nova的组件使用这些API。

    • NOva-api对接受到的HTTP API请求做以下处理:
      (1)检查客户端传入的参数是否合法有效
      (2)调用nova其他服务来处理客户端HTTP请求
      (3)格式化nova其他子服务返回结果并返回给客户端

    • nova-api是外部访问并使用nova提供的各种服务的唯一途径,也是客户端和nova之间的中间层。

    2.2、Scheduler

    Scheduler可译为调度器,由nova-scheduler服务实现,主要解决的是如何选择在哪个计算节点上启动实例的问题。它可以应用多种规则,如果考虑内存使用率、cpu负载率、cpu架构(Intel/amd)等多种因素,根据一定的算法,确定虚拟机实例能够运行在哪一台计算节点。NOva-scherduler服务会从队列中接受虚拟机实例的请求,通过读取数据库的内容,从可用资源池中选择最合适的计算节点来创建新的虚拟机实例

    2.2.1 调度器的类型

    (1)随机调度器(chance scheduler):从所有正常运行nova-compute服务的节点中随机选择
    (2)过滤器调度器(filter scheduler):根据指定的过滤条件以及权重选择最佳的计算节点。Filter又称为筛选器
    (3) 缓存调度器(caching scheduler):可看作随机调度器的一种特殊类型,在随机调度的基础上将主机资源信息缓存在本地内存中,然后通过后台的定时任务定时从数据库中获取最新的主机资源信息

    • 过滤器调度器过程

    通过指定的过滤器选择满足条件的计算节点,比如内存使用小于50%,可以使用多个过滤器依次进行过滤
    对过滤之后的主机进行权重计算并排序,选择最优的计算节点来创建虚拟机实例

    2.2.2 过滤器类型

    • 再审过滤器(RetryFilter)
      主要作用是过滤掉之前已经调度过的节点(类比污点)。如A、B、C都通过了过滤,A权重最大被选中执行操作,由于某种原因,操作在A上失败了。Nova-filter 将重新执行过滤操作,再审过滤器直接过滤掉A,以免再次失败。

    • 可用区域过滤器(AvailabilityZoneFilter)
      主要作用是提供容灾性,并提供隔离服务,可以将计算节点划分到不同的可用区域中。Openstack默认有一个命名为nova的可用区域,所有计算节点一开始都在其中。用户可以根据需要创建自己的一个可用区域。创建实例时,需要指定将实例部署在那个可用区域中。通过可用区过滤器,将不属于指定可用区的计算节点过滤掉。

    • 内存过滤器(RamFilter)
      根据可用内存来调度虚拟机创建,将不能满足实例类型内存需求的计算节点过滤掉,但为了提高系统资源利用率, Openstack在计算节点的可用内存允许超过实际内存大小,可临时突破上限,超过的程度是通过nova.conf配置文件中ram_ allocation_ ratio参数来控制的, 默认值是1.5。(但这只是临时的)
      Vi /etc/nova/nova . conf
      Ram_ allocation_ ratio=1 .5

    • 硬盘过滤器(DiskFilter)
      根据磁盘空间来调度虚拟机创建,将不能满足类型磁盘需求的计算节点过滤掉。磁盘同样允许超量,超量值可修改nova.conf中disk_ allocation_ ratio参数控制,默认值是1.0,(也是临时的)
      Vi /etc/nova/nova.conf
      disk_ allocation_ ratio=1.0

    • 核心过滤器(CoreFilter)
      根据可用CPU核心来调度虚拟机创建,将不能满足实例类型vCPU需求的计算节点过滤掉。vCPU也允许超量,超量值是通过修改nova.conf中cpu_ allocation_ratio参数控制,默认值是16。
      Vi /etc/nova/nova. conf
      cpu_allocation_ ratio=16.0

    • 计算过滤器(ComputeFilter)
      保证只有nova-compute服务正常工作的计算节点才能被nova-scheduler调度,它是必选的过滤器。

    • 镜像属性过滤器(ImagePropertiesFilter)
      根据所选镜像的属性来筛选匹配的计算节点,通过元数据来指定其属性。如希望镜像只运行在KVM的Hypervisor上,可以通过Hypervisor Type属性来指定。

    • 服务器组反亲和性过滤器
      要求尽量将实例分散部署到不同的节点上,设置一个服务器组,组内的实例会通过此过滤器部署到不同的计算节点。适用于需要分开部署的实例。
      服务器组亲和性过滤器
      此服务器组内的实例,会通过此过滤器,被部署在同一计算节点上,适用于需要位于相同节点的实例服务。
      在这里插入图片描述

    • 调度器与DB的交互过程
      scheduler组件决定的是虚拟机实例部署在哪台计算节点上并调度,在调度之前,会先向数据库获取宿主机资源信息作为依据;之后可通过过滤器和权重选择最合适的节点调度,或者指定节点直接调度;计算节点的 libvirt 工具负责收集宿主机的虚拟化资源,根据已创建的实例再次统计资源,将资源信息更新到数据库中,整个更新资源信息的过程是周期性执行的,而不是实时的,所以存在一个问题,当刚创建完一个实例,随即又需要创建时,数据库还未来得及更新宿主机的最新状态,那么调度器依据的信息就不正确,有可能所选的节点资源并不够用,而导致调度失败。这同时也是缓存调度器的缺陷,无法实时获取租主机资源信息。我们可在调度完成时,直接将资源信息返回给数据库,更新数据库状态,解决这个问题。

    2.3、Nova-compute

    Nova-compute处理管理实例生命周期。他们通过Message Queue接收实例生命周期管理的请求,并承担操作工作。在一个典型生产环境的云部署中有一些compute workers。一个实例部署在哪个可用的compute worker上取决于调度算法。

    2.4、Rabbitmq

    OpenStack 节点之间通过消息队列使用AMQP(Advanced Message Queue Protocol)完成通信。Nova 通过异步调用请求响应,使用回调函数在收到响应时触发。因为使用了异步通信,不会有用户长时间卡在等待状态。这是有效的,因为许多API调用预期的行为都非常耗时,例如加载一个实例,或者上传一个镜像。

    2.5、Nova-conductor

    nova-conductor是nova-compute与数据库的中间件,nova-compute对数据库的CRUD操作都借由nova-conductor完成,nova-conductor通过rpc对外提供API服务。nova-conductor默认采用多进程运行,在不配置[conductor]worker的情况下,进程数会与服务器的逻辑CPU数一致。

    三、Nova的工作流程

    • 其他组件需要nova调用资源时,会先去keystone组件那拿到token令牌,然后拿着令牌给nova-api看,nova-api也要拿着token令牌去找keystone验证,验证成功后,nova内部的组件就开始各司其职了
    • nova-api要找到相应的组件来干活,之前外部所需要的资源信息就放入DB数据库中,然后通过消息队列来告诉nova-scheduler,让它来安排一下
    • 接着nova-scheduler通过自己的一系列调度算法(例如内存使用率,cpu负载率,,cpu架构等)来确定在那台计算节点上运行,看到DB数据库中所需要的资源信息,通过自己的调度算法,给nova-compute交代任务。
    • 因为nova-compute的处于云主机上,安全性不高,所以nova-compute不知道DB数据库在哪,然后nova-compute就让nova-conductor去DB查看来告诉自己相关消息。
    • 最后nova-compute看到DB数据库的信息,就拿着token令牌去其他openstack组件拿相应资源,(例如,glance镜像服务,cinder磁盘空间等)
    展开全文
  • 通过 git clone 命令下载 nova,下载链接如下:运行命令:git clone https://github.com/openstack/nova.g
  • openstack集群部署 1、openstack-train版本集群部署 2、openstack自定义ubuntu、centos镜像 3、上传镜像到openstack,用网页版创建虚拟机
  • openstack 部署方式 kolla-ansible 使用 kolla-ansible 部署方式时,所有组件的日志文件会外挂到宿主机上(都是使用容器启动的),可以在相应节点的 /var/log/kolla/ 目录下查看,下图为各个组件的日志目录 进入你想...
  • OpenStack中提供镜像服务的是Glance,其主要功能如下: 查询和获取镜像的元数据和镜像本身 注册和上传虚拟机镜像,包括镜像的创建、上传、 下载和管理 维护镜像信息,包括元数据和镜像本身。 ...
  • 组件部分 ceilometer-agent-compute:运行在每个计算节点上,循环查询资源使用率,统计情况 ceilometer-agent-central:运行在管理服务器上 ceilometer-agent-notification:运行在管理服务器上,使用消息队列中的...
  • 1 openstack组件之间通信以及组件内各服务通信方式 1.1 openstack各组件之间的通信方式 据我所了解的几个组件,各个组件之间大部分是通过调用其他组件的rest api方式进行通信, 而rest api的框架大部分是通过: ...
  • Openstack组件之glance组件详细解析

    千次阅读 2020-12-21 19:27:55
    glance即image service,是为虚拟机的创建提供镜像的服务,我们基于openstack是构建基本的Iaas平台对外提供虚拟机,而虚拟机在创建时必须为选择需要安装的操作系统,glance服务就是为该选择提供不同的操作系统镜像
  • Neutron服务就是提供网络支持,通过使用代理,插件,来为集群内部的组件/实例提供网络资源 网络是openstack最重要的资源之一,没有网络,虚拟机将被隔离。Openstack的网络服务最主要的功能就是为虚拟机实例提供网络...
  • OpenStack组件详解——Glance镜像服务

    千次阅读 2020-12-20 21:20:31
    glance服务是OpenStack中负责给实例提供image镜像的服务,就是服务镜像的上传和下载操作,他可以上传各种操作系统的镜像,windows的可以,Ubuntu可以,centos可以,只要你用到的都可以传上去。而且他的镜像
  • 要想学好云计算,openstack学习的好资料。由权威及项目经验丰富的教授教学
  • openstack组件卸载命令等2个文件
  • OpenStack组件介绍

    千次阅读 2017-11-10 11:34:07
    又被称为 OpenStack Compute,主要作用是控制虚拟机的创建,以及改变它的容量和配置,还可以做虚拟机的销毁,虚拟机的整个生命周期都是由 Nova 来控制的; Nova的部署运行一般有两种情况:一类是 Nova 作为 ...
  • OpenStack主要组件

    千次阅读 2022-02-05 16:38:57
    OpenStack主要组件1. OpenStack Compute(Nova)2 OpenStack Storage2.1 OpenStack Object Storage(Swift)2.2 OpenStack Block Storage(Cinder)3. Networking(Neutron)4. Dashboard(Horizon)5. 其他共享服务...
  • Openstack 组件 Oslo

    2021-11-13 22:06:39
    Openstack 组件 Oslo Oslo简介 随着OpenStack项目的不断发展与完善,OpenStack社区将所有组件中的具有共性的组件剥离出来,并统一放在oslo组件下。oslo中的组件不仅可以在OpenStack项目中使用,也可以单独作为第三方...
  • 组件间的关系: Horizon和KeyStone服务和所有组件都有联系 剩下的服务都是以虚拟机为主体进行运转 控制访问流程图:
  • OpenStack组件——Keyston身份认证服务

    千次阅读 2021-08-28 23:45:10
    OpenStack组件——Keyston身份认证服务 一、Keystone身份服务简介 1.1、概述:主要功能 1.2、管理对象 1.3keystone认证过程⭐⭐⭐ 二、Keystone身份认证服务组件部署安装 2.1、创建数据库实例和数据库用户 2.2、安装...
  • 目录目录 前文列表 Prerequisites 先决条件 Install and configure a compute node ...Finalize installation前文列表Openstack组件部署 — Overview和前期环境准备 Openstack组建部署 — Environme

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 27,232
精华内容 10,892
关键字:

openstack组件