用户的身份认证(Authentication)是基于密钥机制的。
用户对资源的访问控制是基于权能(Capability)机制进行授权(Authorization)的。
Capability是用于访问控制的一种数据结构,它定义了对一个或多个指定的资源(如目录、文件、表等)所具有的访问权限。用户访问飞天系统的资源时必须持有Capability,否则即视为非法。打一个比方,如果把Capability理解为地铁票,乘坐地铁(对地铁的一种访问方式)的时候必须要有Capability,即地铁票。
密钥对是基于公开密钥方法的,包括一个私钥和相对应的公钥。在飞天平台系统中,密钥对用于数字签名服务,以保证Capability的不可伪造。换句话说,私钥用于产生数字签名(如签发Capability),公钥用于验证数字签名的有效性(如验证签发过的Capability的有效性)。
考虑到网络通信时任何通信节点都是不可信的,所以即使是飞天自身模块内部之间的通信也同样是需要认证和授权的,而且验证的机制也完全一样。
分布式文件系统(盘古)
盘古(Pangu)是一个分布式文件系统,盘古系统的设计目标是将大量通用机器的存储资源聚合在一起,为用户提供大规模、高可靠、高可用、高吞吐量和可扩展的存储服务,是飞天平台内核中的一个重要组成部分。
大规模:能够支持数十PB量级的存储大小(1PB=1000TB),总文件数量达到亿量级。
数据高可靠性:保证数据和元数据(Metadata)是持久保存并能够正确访问的,保证所有数据存储在处于不同机架的多个节点上面(通常设置为3)。即使集群中的部分节点出现硬件和软件故障,系统能够检测到故障并自动进行数据的备份和迁移,保证数据的安全存在。
服务高可用性:保证用户能够不中断地访问数据,降低系统的不可服务时间。即使出现软硬件的故障、异常和系统升级等情况,服务仍可正常访问。
高吞吐量:运行时系统I/O吞吐量能够随机器规模线性增长,保证响应时间。
高可扩展性:保证系统的容量能够通过增加机器的方式得到自动扩展,下线机器存储的数据能够自动迁移到新加入的节点上。
同时,盘古系统也能很好地支持在线应用的低延时需求。在盘古系统中,文件系统的元数据存储在多个主服务器(Master)上,文件内容存储在大量的块服务器(Chunk Server)上。客户端程序在使用盘古系统时,首先从主服务器获取元数据信息(包括接下来与哪些块服务器交互),然后在块服务器上直接进行数据操作。由于元数据信息很小,大量的数据交互是客户端直接与块服务器进行的,因此盘古系统采用少量的主服务器来管理元数据,并使用Paxos协议保证元数据的一致性。此外,块大小被设置为64MB,进一步减少了元数据的大小,因此可以将元数据全部放到内存里,从而使得主服务器能够处理大量的并发请求。
块服务器负责存储大小为64MB的数据块。在向文件写入数据之前,客户端将建立到3个块服务器的连接,客户向主副本(Replica)写入数据以后,由主副本负责向其他副本发送数据。与直接由客户端向3个副本写入数据相比,这样可以减少客户端的网络带宽使用。块副本在放置的时候,为保证数据可用性和最大化地使用网络带宽,会将副本放置在不同机架上,并优先考虑磁盘利用率低的机器。当硬件故障或数据不可用造成数据块的副本数目不满3份时,数据块会被重新复制。为保证数据的完整性,每块数据在写入时会同时计算一个校验值,与数据同时写入磁盘。当读取数据块时,块服务器会再次计算校验值与之前存入的值是否相同,如果不同就说明数据出现了错误,需要从其他副本重新读取数据。
在线应用对盘古系统提出了与离线应用不同的挑战:OSS、OTS要求低时延数据读写,ECS在要求低时延的同时还需要具备随机写的能力。针对这些需求,盘古系统实现了事务日志文件和随机访问文件,用于支撑在线应用。其中,日志文件通过多种方法对时延进行了优化,包括设置更高的优先级、由客户端直接写多份拷贝而不是用传统的流水线方式、写入成功不经过Master确认等。随机访问文件则允许用户随机读写,同时也应用了类似日志文件的时延优化技术。
资源管理和任务调度(伏羲)
伏羲(Fuxi)是飞天平台内核中负责资源管理和任务调度的模块,同时也为应用开发提供了一套编程基础框架。伏羲同时支持强调响应速度的在线服务和强调处理数据吞吐量的离线任务。在伏羲中,这两类应用分别简称为Service和Job。
在资源管理方面,伏羲主要负责调度和分配集群的存储、计算等资源给上层应用;管理运行在集群节点上任务的生命周期;在多用户运行环境中,支持计算额度、访问控制、作业优先级和资源抢占,在保证公平的前提下,达到有效地共享集群资源。
在任务调度方面,伏羲面向海量数据处理和大规模计算类型的复杂应用,提供了一个数据驱动的多级流水线并行计算框架,在表述能力上兼容 MapReduce、Map-Reduce-Merge等多种编程模式;自动检测故障和系统热点,重试失败任务,保证作业稳定可靠运行完成;具有高可扩展性,能够根据数据分布优化网络开销。
伏羲中应用了“Master/Worker”工作模型。其中,Master负责进行资源申请和调度、为Worker创建工作计划(Plan)并监控Worker的生命周期,Worker负责执行具体的工作计划并及时向Master汇报工作状态(Status)。此外,Master支持多级模式,即一个Master可以隶属于另外一个Master之下。
伏羲Master负责整个集群资源管理和调度,处理Job/Service启动、停止、Failover等生命周期的维护。同时伏羲 Master支持多用户额度配置、Job/Service的多优先级设置和动态资源抢占逻辑,可以说是飞天平台的“大脑”。伏羲对资源调度是多维度的,可以根据CPU、内存等系统资源,以及应用自定义的虚拟资源对整个机群进行资源分配和调度。
土伯(Tubo)是部署在每台由伏羲管理的机器上的后台进程,负责收集并向伏羲Master报告本机的状态,包括系统资源的消耗、Master 或Worker进程的运行、等待、完成和失败事件,并根据伏羲Master或者Job/Service Master的指令,启动或杀死指定的Master或Worker进程。同时土伯还负责对计算机健康状况进行监控,对异常Worker(比如内存超用)进行及时的清理和汇报。
原文转自:http://kb.cnblogs.com/page/183553/