OpenStack学习（一）——基础组件

OpenStack Dashboard(Horizon,管理界面)：

      提供了一个基于web的自服务门户，与OpenStack底层服务交互，诸如启动一个实例，分配IP地址以及配置访问控制。

 OpenStack Compute(Nova,计算管理):
        OpenStack的组织控制器，提供一个工具来部署云，包括运行实例、管理网络以及控制用户和其他项目对云的访问。
        Nova各组件的作用：
            a) nova-api守护进程是OpenStack Compute的中心。它为所有API查询提供端点，初始化绝大多数部署活动(比如运行实 例)，以及实施一些策略(绝大多数的配额检查)；
            b) nova-compute进程主要是一个部署在HOST上的守护进程，通过虚拟机管理程序的API创建和终止虚拟机实例。基本原 理：从队列中接收行为，然后在更新数据库的状态时，执行一系列的系统命令执行他们；
            c) nova-volume给虚拟机分配额外持久化的存储，管理映射到计算机实例的卷的创建、附加和取消；
            d) nova-network worker守护进程类似于nova-compute和nova-volume。它从队列中接收网络任务，然后执行任务以操控 网络，比如创建bridging interfaces或改变iptables rules；
            e) Queue提供中心hub，为守护进程传递消息。当前用RabbitMQ实现。但是理论上能是python ampqlib支持的任何AMPQ消息队列。
                AMPQ：Advanced Message Queuing Protocol，即高级消息队列协议。
                主要特征是面向消息、队列、路由、可靠性和安全。
            f) SQL database存储云基础架构中的绝大多数编译时和运行时状态。这包括了可用的实例类型，在用的实例，可用的网络和项目。当前广泛使用的数据库是sqlite3(仅适合测试和开发工作)，MySQL和PostgreSQL；
            g) OpenStack Glance，是一个单独的项目，它是一个compute架构中可选的部分，分为三个部分：glance-api, glance-registry and the image store. 其中，
                glance-api接受API调用，
                glance-registry负责存储和检索镜像的元数据，实际的Image Blob存储在Image Store中。Image Store可以是多种不同的Object Store，包括OpenStack Object Storage (Swift)；
            h) user dashboard是另一个可选的项目。OpenStack Dashboard提供了一个OpenStack Compute界面来给应用开发者和devops staff类似API的功能。
            i) nova-schedule,从队列上得到一个虚拟机实例请求并且决定它应该在哪里运行(特别是它应该运行在哪台计算服务器主机之上)
            
        nova计算虚化：
            1) 基于REST API；
            2) 支持大容量水平扩展；
            3) 硬件无关，支持多种标准硬件；
            4) 虚拟化平台无关，支持多种Hypervisor：KVM、LXC、QEMU、UML、ESX、Xen、PowerVM、Hyper-V
        
        服务架构：
        OpenStack Compute采用无共享、基于消息的架构。
        这意味着安装OpenStack Compute有多种可能的方法。可能多结点部署唯一的联合依赖性，是Dashboard必须被安装在 nova-api服务器。几种部署架构如下：
            a) 单结点：一台服务器运行所有的nova-services，同时也驱动虚拟实例。
                        这种配置只为尝试OpenStack Compute，或者为了开发目的;
            b) 双结点：一个cloud controller 结点运行除nova-compute外的所有nova-services，compute结点运行nova-compute。一台客户计算机很可能需要打包镜像，以及和服务器进行交互，但是并不是必要的。
                        这种配置主要用于概念和开发环境的证明。
            c) 多结点：通过简单部署nova-compute在一台额外的服务器以及拷贝nova.conf文件到这个新增的结点，能在两结点的基础上，添加更多的compute结点，形成多结点部署。在较为复杂的多结点部署中，还能增加一个volume controller 和一个network controller作为额外的结点。
                        对于运行多个需要大量处理能力的虚拟机实例，至少是4个结点是最好的。

 OpenStack Object Storage(Swift,对象存储)：
        可扩展的对象存储系统。
        Swift提供存储供不同存储消费者和客户使用，每个用户需要通过认证来识别自己。为此，OpenStack Object Stoage提供了 一个授权系统（swauth）。
            1) 基于REST API；
            2) 数据在整个系统中均匀分布；
            3) 硬件无关，支持多种标准硬件；
            4) 没有中央数据库，没有单点性能瓶颈或单点失败的隐患
            5) 易于扩展；
            6) Account/Container/Object三级存储结构均无需文件系统且均有N(>=3)份拷贝
        一些相关的概念(暂时还不是很理解)：
            a） Account和Account Servers
            b） Authentication 和 Access Permissions
            c） Containers and Objects
            d） Operations
            e） 特定语言的API绑定
        
        Object Storage如何工作：
            a) Ring
                Ring 代表磁盘上存储的实体的名称和它们的物理位置的映射。
                accounts, containers, and objects都有单独的Ring。其他组件要在这三者之一进行任何操作，他们都需要合相应的Ring进行交互以确定它在集群中的位置。
                Ring用zones，devices，partitions，和replicas来维护映射，在Ring中的每个分区都会在集群中默认有三个副本。分区的位置存储在Ring维护的映射中。
                Ring也负责确定失败场景中接替的设备。分区的副本要保证存储在不同的zone。Ring的分区分布在OpenStack Object Storage installation所有设备中。
                分区需要移动的时候，Ring确保一次移动最少的分区，一次仅有一个分区的副本被移动。
            b) Proxy Server
                Proxy服务器的功能可以总结为：查询位置，处理失败，中转对象。
                Proxy负责将OpenStack Object Storage架构中其他部分结合在一起。对于每次请求，它都查询在Ring中查询account, container, or object的位置，并以此转发请求。公有APIs也是通过代理服务器来暴露的
                当一个服务器不可用，它就会要求Ring来为它找下一个接替的服务器，并把请求转发到那里。
                当对象流进或流出object server时，它们都通过代理服务器来流给用户，或者通过它从用户获取。代理服务器不会缓冲它们。
            c) Object Server
                简单的blob存储服务器，能存储、检索和删除本地磁盘上的对象，它以二进制文件形式存放在文件系统中，元数据以文件的扩展属性存放。
            d) Container Server
                其主要工作是处理对象列表，它不知道对象在哪里，只是知道哪些对象在一个特定的container。
                列表被存储为sqlite 数据库文件，类似对象的方式在集群中复制。也进行了跟踪统计，包括对象的总数，以及container中使用的总存储量。
            e) Account Server
                它是类似于Container Server，除了它是负责containers的列表而非对象。
            f) Replication
                设计副本的目的是，在面临网络中断或驱动失败等临时错误条件时，保持系统在一致的状态。
                副本进程会比较本地的数据和每个远处的副本，以确保他们所有都包含最新的版本。对象副本用一个Hash列表来快速比较每个分区的片段，而container和 account replication 用的是Hash和共享的高水印结合的方法。
                副本的更新，是基于推送的。对于对象副本，更新是远程同步文件到Peer。Account和container replication通过HTTP or rsync把整个数据库文件推送遗失的记录。
                副本也通过tombstone设置最新版本的方式，确保数据从系统中清除。
            g) 更新器(Updaters)
                失败的情形或高负载时期，container 或 account数据可能不能被立即更新。该更新会在文件系统上本地排队，更新器 将处理这些失败的更新。
                事件一致性窗口(eventual consistency window)最可能来起作用。
            h) Auditors
                Auditors会检查objects, containers, 和 accounts的完整性。如果发先损坏的文件，它将被隔离，好的副本将会取代这个坏的文件。如果发现其他的错误，它们会记入到日志中
    
OpenStack Image Sevice(Glance,镜像管理):
        虚拟机镜像的存储、查询和检索系统，服务包括的RESTful API允许用户通过HTTP请求查询VM镜像元数据，以及检索实际的镜像。
        VM镜像四种配置方式：
            (1) 简单的文件系统;
            (2) 类似OpenStack Object Storage的对象存储系统;
            (3) 直接用Amazon'sSimpleStorageSolution(S3)存储;
            (4) 用带有Object Store的S3间接访问S3。
            
        包括两个主要的部分，分别是API server和Registry server
            API Server(运行“glance api”程序)起通信hub的作用。
            API server转发客户端的请求到镜像元数据注册处和它的后端仓储。OpenStack Image Service就是通过这些机制来实际保存进来的虚拟机镜像。
        
        支持的后端仓储：
            a) OpenStack Object Storage。它是OpenStack中高可用的对象存储项目。
            b) FileSystem。OpenStack Image Service存储虚拟机镜像的默认后端是后端文件系统。这个简单的后端会把镜像文件写到本地文件系统。
            c) S3。该后端允许OpenStack Image Service存储虚拟机镜像在Amazon S3服务中。
            d) HTTP。OpenStack Image Service能通过HTTP在Internet上读取可用的虚拟机镜像。这种存储方式是只读的。

        根据安装手册，两个服务安装在同一个服务器上。镜像本身则可存储在OpenStack Object Storage， Amazon's S3                    infrastructure，fileSystem。如果只需要只读访问，可以存储在一台Web服务器上。
        

OpenStack Networking(Neutorn,虚拟网络管理)：
      确保为其它OpenStack服务提供网络连接即服务，比如OpenStack计算。为用户提供API定义网络和使用。基于插件的架构其支持众多的网络提供商和技术。
      主要组件包括：
            a) Neutron Service
            b) Core Plugin(插件)
            c) 各种Advanced Service Plugin
            d) 各种Agent(代理)
                L2(ovs-agent)
                L3 Agent
                DHCP Agent(DHCP：全称是 Dynamic Host Configuration Protocol﹐中文名为动态主机配置协议)
                MetaData Agent
           Neutron Plugin通过集成多种虚拟环境网络插件，实现L2的虚拟网络管理
        
 OpenStack Block Storage(Cinder,块存储管理)：
        为运行实例而提供的持久性块存储。它的可插拔驱动架构的功能有助于创建和管理块存储设备。
            1) 虚拟机管理和发放(Nova)、卷管理和发放为独立服务；
            2) 虚拟机、卷生命周期独立；
            3) 众多传统存储厂商（EMC，Netapp，IBM，HP）、虚拟化存储厂商（VMWare，XenServer，Windows、新兴存储厂商（SolidFire，Ceph）都接入Cinder，以期发挥产品优势
            
OpenStack Identity Service(Keystore,鉴权)：
        为其他OpenStack服务提供认证和授权服务，为所有的OpenStack服务提供一个端点目录
            1) user：一个使用openstack云服务的人、系统或者服务。
            2) project：项目，一组资源集合，包括虚拟资源如网络、虚拟机、卷等资源关联。
            3) role：用户角色，和policy配合使用。
            4) token：一个通过keystone验证的用户标识，它的范围与user+project或者user+domain关联，根据获取的token的方式来区分。
            5) service：compute，image，identity，volume，network。
            6) endpoint：service的网络接入地址，具有region属性。
            7) group：用户的集合，便于给用户整体授予和取消权限
            8) domain：类似命名空间，含有用户、角色、Group、Project等。
            9) policy：对于服务的操作规则，和角色相关，可以定义哪个角色可以进行哪些操作（v3版本只增加了crud操作，没有逻辑实现替代policy.json的功能）
            10) trust：一个用户可以通过trust将自己的role和个人信息转交给另一个用户使用
        认证流程：
            1) 用户发起nova请求之前，首先需要验证用户身份；
            2) 若用户对应的credential通过keystone认证，keystone返回token；
            3) 用户发起nova请求，请求信息中带上token ID；
            4) nova会再次向keystone验证token有效性，若keystone返回有效，执行下一步操作。

 

七个服务之间的相互联系如下图：

    
除了上部分的七个主要服务外，其他还有：
      OpenStack Telemetry Service(Ceilometer)：为OpenStack云的计费、基准、扩展性以及统计等目的提供监测和计量
      OpenStack Orchestration Service(Heat)：
        既可以使用本地模板格式，亦可使用AWS CloudFormation模板格式，来编排多个综合的云应用，通过OpenStack本地             REST API或者是CloudFormation相兼容的队列API。
        Heat是OpenStack中的Orchestration services，也就是应用程序的配置管理。
        Heat用声明式的方法来管理公有云或者私有云中的应用程序。它和其他OpenStack的服务类似，对外提供ReSTful接口，但     除此之外，它定义了一套配置管理的模版。Heat的模版才是Heat的核心所在；
        Heat与Openstack各服务间采用OpenStack-native Rest API
        Heat中的基本术语：
            1) 栈：栈是CloudFormation中管理一组资源的基本单位。一个栈往往对应与一个应用程序。
            2) 资源：一个栈可以拥有很多资源， 资源是底层服务的抽象。CPU，memory，disk，网络等都可以看作是资源。资源和资源之间会存在依赖关系。Heat在创建栈的时候会自动解析依赖关系，按顺序创建资源。