×

云计算技术及应用 思考题整理

96
这就是一个随意的名字
2016.12.25 11:30* 字数 15428

云计算技术及应用 课程思考题整理

by Syf
2016-12-19
v0.4

课程版本为2016-2017学年度年秋季学期莫Sir的《云计算技术及应用》,题目答案为自行整理,仅供参考,如有错误,欢迎指正


1. 云计算概述

1.1 什么是云计算

云计算的概念范畴仍在探索中,尚无统一明确的定义
wiki:

云计算是一种能够将动态伸缩的虚拟化资源通过互联网以服务的方式提供给用户的计算模式。

莫Sir:

  • 新的资源提供模式
  • 新的应用模式
  • 新的技术模式

1.2 云计算的优势

  • 优化产业布局
  • 推进专业分工
  • 提升资源利用率
  • 减少初期投资
  • 降低管理开销

1.3 云计算的动因

  • 芯片与硬件技术:摩尔定律;硬件能力的激增、成本的大幅下降,使得独立运作的公司集中客观的硬件能力实现规模效益成为可能
  • 资源虚拟化:资源在云端,需要被统一的管理;异构硬件的兼容性问题;虚拟化技术的应用
  • 面向服务的架构SOA:开放式数据模型,统一通信标准,更加丰富的服务,更加松散耦合、灵活的IT架构,转变了人们对IT系统的认识
  • 软件即服务SaaS:转变了人们使用服务的方式,使得终端用户熟悉服务的交互模式,改变了IT界的商业模式,实力雄厚的大公司负责基础设施,小企业通过创新挖掘充满潜力的市场
  • 互联网技术的改变
  • Web2.0技术

2. 云服务

2.1 云服务的基本层次

  • IaaS Infrastructure as a Service 基础设施即服务
  • PaaS Platform as a Service 平台即服务
  • SaaS Software as a Service 软件即服务

2.2 IaaS的基本功能

  • 资源的抽象、监控、部署,数据、负载、安全、计费的管理
    • 资源抽象:(核心问题:对资源进行粒度划分并管理 )
      对硬件进行虚拟化,屏蔽硬件产品差异,对硬件进行统一的管理逻辑,粒度分级概念,将物理资源放入统一的资源池中,对资源池进行管理并呈现给用户
    • 资源监控:对不同资源采取不同监控方式
    • 负载管理:实现负载均匀,避免负载过高,负载平衡与优化问题
    • 数据管理:多种数据并存,物理上分布式存储,对数据的完整性、可靠性、可管理性提出挑战完整性,可靠性,可管理性
    • 资源部署:典型场景:支持动态资源可伸缩性,故障恢复与硬件维护
    • 安全管理:保证基础设施资源被合法地访问和使用,合法性,云数据安全的保障
    • 计费管理:变买为租,按量、按时间计费,使用情况监控,用户任务的多种实现方式

2.3 PaaS的基本功能

  • 为云应用提供开发、运行、管理和监控的环境
  • 核心功能
    • 开发平台:
      平台层是其上运行的应用的开发平台,应用模型,API代码库,必要的开发测试环境
    • 运行时环境:
      隔离性、可伸缩性、资源的可复用性
    • 运营环境:
      应用更新、升级、监控,资源消耗监控,卸载,计费统计

4. 虚拟化技术

4.1 虚拟化的概念

  • 将原本存在于真实环境上的计算机系统或组件运行在虚拟出来的环境中,解除真实环境中各个层次的耦合关系。

Wiki:

虚拟化是表示计算机资源的抽象方法,通过虚拟化可以用与访问抽象前资源一致的方法来访问抽象后的资源。这种资源的抽象方法并不受实现、地理位置或底层资源的物理配置限制。

  • 虚拟化的对象是各种各样的资源
  • 经过虚拟化后的逻辑资源对用户隐藏了不必要的细节
  • 用户可以在虚拟环境中实现其在真实环境中的部分或全部功能

4.2 服务器虚拟化的特性

  • 服务器虚拟化:将虚拟化技术应用于服务器上,将物理服务器虚拟化为多个虚拟服务器(其中包括虚拟BIOS、虚拟处理器、虚拟内存、虚拟设备与IO)
  • 特点:
    • 多实例:一个物理服务器上可以运行多个虚拟服务器,还支持多个客户操作系统,物理系统资源以可控的方式分配给虚拟机。
    • 隔离性:虚拟机之间完全隔离,一个虚拟机崩溃不会对其他虚拟机造成影响,虚拟机之间的数据相互独立、不会泄露,虚拟机之间如果需要互相访问,方式等同于独立物理服务器之间的互相访问。
    • 封装性:与硬件无关,对外表现为单一的逻辑实体,一个虚拟机可以方便地在不同硬件之间复制、移动,将不同访问方式的硬件封装成统一标准化的虚拟硬件设备,保证了虚拟机的兼容性。
    • 高性能:可通过扩展获得“无限”的性能,虚拟化抽象层需要一定的管理开销。

4.3 服务器虚拟化的关键技术

  • 计算虚拟化:CPU虚拟化,计算负载的动态分配,能耗管理
  • 存储虚拟化:内存虚拟化,磁盘存储动态分配
    • 内存虚拟化:影子页表法(左)、页表写入法(右)
影子页表法(左)、页表写入法(右)
  • 设备与I/O虚拟化:软件方式实现, 统一、标准化的接口,操作指令转译
  • 实时迁移技术
    • 将整个虚拟机的运行状态完整、快速地从原宿主机的硬件平台转移到新的宿主机硬件平台
    • 实时性
    • 内存页面不断滴从源虚拟机监视器拷贝到目标虚拟机监视器
    • 拷贝结束后,目标虚拟机开始运行,虚拟机监视器切换到目标虚拟机上,源虚拟机终止
      -- 广泛应用于实时系统的硬件维护

4.4 其他虚拟化的相关技术

  • 网络虚拟化:虚拟MAC,VLAN,VPN
    • VLAN 虚拟局域网
      • 虚拟局域网(VLAN)是一组逻辑上的设备和用户,这些设备和用户并不受物理位置的限制,可以根据功能、部门及应用等因素将它们组织起来,相互之间的通信就好像它们在同一个网段中一样。
      • VLAN工作在OSI参考模型的第2层和第3层,一个VLAN就是一个广播域,VLAN之间的通信通过第3层的路由器完成。
      • VLAN网络可以是有混合的网络类型设备组成,比如:以太网、令牌网、FDDI等。
      • 常见用于满足内部网络管理需要
    • VPN 虚拟专用网络:通过对数据包的加密和数据包目标地址的转换实现远程访问
      • 通过架设VPN服务器,外部人员通过互联网连接VPN服务器,然后通过VPN服务器进入内网。为了保证数据安全,VPN服务器和客户机之间的通讯数据都进行了加密处理。有了数据加密,可以认为数据是在一条专用的数据链路上进行安全传输,就如同专门架设了一个专用网络一样,但实际上VPN使用的是互联网上的公用链路,因此VPN称为虚拟专用网络,其实质上就是利用加密技术在公网上封装出一个数据通讯隧道
      • VPN的隧道协议主要有三种,PPTP、L2TP和IPSec,其中PPTP和L2TP协议工作在OSI模型的第二层,又称为二层隧道协议;IPSec是第三层隧道协议。
  • 存储虚拟化:磁盘阵列RAID,网络存储技术NST
    • RAID
      • RAID0:连续以位或字节为单位分割数据,并行读/写于多个磁盘,没有数据可靠性保证,单纯提高性能
      • RAID1:通过磁盘数据镜像实现数据冗余,成对的独立磁盘上相互备份,可直接从镜像拷贝中读取数据以提高性能,高性能、高安全性,代价是高成本
      • RAID10
      • RAID3:磁盘的损坏是小概率事件,少量的校验信息替代完整的备份,只要损坏的磁盘数不影响校验即可保障可靠性,独立磁盘存储校验信息,数据盘失效可由其他盘恢复,校验盘失效不影响数据使用
      • RAID5:类似raid3,各盘交叉存储数据和校验信息,没有独立的校验盘,大部分操作只涉及少量磁盘,可并行操作
      • 其他RAID标准
    • 网络存储技术NST
      • 直连式存储(DAS:Direct Attached Storage)
      • 网络存储设备(NAS:Network Attached Storage)
      • 存储网络(SAN:Storage Area Network)
RAID0
RAID1
RAID10
RAID3
RAID5
  • 桌面虚拟化:可以通过瘦客户端或其他与网络相连的设备访问跨平台的应用程序,以及整个客户桌面
  • 应用虚拟化:将应用与底层系统和硬件相分离,屏蔽了可能与其他应用产生冲突的内容,无需安装、卸载
  • 容器虚拟化
    • LXC
    • Docker:基于进程容器(Processcontainer)的轻量级VM解决方案
      • Docker对container的改进
        • 高级封装,提供各种辅助工具和标准接口使得更简洁易用
        • 额外功能包括:标准统一的打包部署运行方案, 历史版本控制, Image的重用,Image共享发布
        • 构建一次,在各种平台上运行
        • PaaS层的典型支撑
      • Docker的主要特点
        • 传统VM各自包含独立的操作系统
        • 容器包含应用和它所有的依赖,但是与其它containers共享操作系统内核
        • 像用户空间独立的进程一样运行在主机操作系统上
        • Docker容器并不是只能运行在特定的架构上
        • 联想——“绿色免安装硬盘版”

4.5 典型虚拟机

  • KVM:Kernel-based Virtual Machine
    开源虚拟化模块,集成在Linux的各个主要发行版本中,使用Linux自身的调度器进行管理
    CPU管理——Intel VT-x技术
    内存管理——影子页表法
    设备管理——I/O数据包转发
  • Xen

4.6 虚拟化与云计算的关系

  • 虚拟化技术的运用,使得云计算中的计算、存储、应用、和服务都变成了资源,这些资源可以被动态的扩展和配置,实现了让云计算在逻辑上以单一整体形式呈现的特性。
  • 云计算是一种基于互联网的计算方式,通过这种方式,共享的软硬件资源和信息可以按需求提供给计算机和其他设备,主要是基于互联网的相关服务的增加、使用和交付模式,通常涉及通过互联网来提供动态易扩展且经常是虚拟化的资源。
  • 虚拟化是云计算发展的动因之一,构成云计算的基础。虚拟化技术使得硬件资源可以被
    有效的细粒度分割和管理,以服务方式提供硬件和软件资源成为可能。
  • 虚拟化为云计算提供了很好的底层技术平台。云计算是在虚拟化出若干资源池以后的应用。

5. 虚拟化资源管理

5.1 AWS模式是什么,有什么优点?

Amazon Web Service的简称,是一个典型的 IaaS 服务。提供了一组服务,包括存储(S3)、计算 EC2、网络、消息传递和数据库服务等。用户应用使用 IaaS 基础 IT 资源,将 PaaS 和通用服务作为应用架构中的组件来构建自己的服务。用户所需要的 IT 资源不在公司自己的数据中心里面,这些资源可以通过互联网获得,没有固定的投资成本。

  • 特点:
    1. 通过 Web Service 接口开放数据和功能
    2. 一切以服务实现
    3. 通过 SOA 架构使系统达到松耦合
  • 优点:
    1. 按需租用,按用付费,无需考虑硬件、维护等成本
    2. 一切通过服务提供
    3. 完全的 SOA 架构,各部分相互独立提供服务
    4. 良好的扩展性和弹性设计

5.2 IaaS模式核心需求有哪些?

  • 云拥有者:配置和操作基础架构
  • 服务的提供者:注册云服务,查看服务的使用、计费情况
  • 服务的使用者:创建和存储自定义的镜像,启动、监控、终止实例

5.3 Openstack都包含哪些核心项目,作用是什么?

  • Compute (nova) 计算:计算组织控制器,是负责管理计算资源、网络、认证、所需可扩展性的平台
  • Ojbect storage (swift) 对象存储:为Nova提供虚机镜像存储服务
  • Image service (glance) 镜像服务:提供虚拟机镜像的发现,注册,取得服务
  • Identity (keystone) 身份服务:为其他服务提供身份验证、服务规则和服务令牌的功能
  • Dashboard (horizon) UI界面:各种服务的Web管理门户,用于简化用户对服务的操作
  • Network (Neutron) 网络和地址管理:提供云计算的网络虚拟化技术,为OpenStack其他服务提供网络连接服务,为用户提供接口
  • Block storage (cinder) 块存储:为运行实例提供稳定的数据块存储服务

5.4 镜像和实例有什么区别和联系?

镜像是计算、存储服务的载体,是抽象的、逻辑的;实例则是镜像的一个具体实现,镜像的设计是为了实现大量实例的管理。

5.5 Nova有哪些核心模块,工作过程是什么?

  • 核心模块:
    1. nova-compute:负责对虚拟机实例进行创建、终止、迁移、Resize的操作。从队列中接收请求,通过相关的系统命令执行他们,再更新数据库的状态。
    2. nova-volume:管理映射到虚拟机实例的卷的创建、附加和取消。
    3. nova-network:从队列中接收网络任务,然后执行任务控制虚拟机的网络。
    4. nova-scheduler:提供调度,来决定在哪台资源空闲的机器上启动新的虚拟机实例
    5. Queue为守护进程传递消息。
    6. SQL database:存储云基础架构中的各种数据。包括了虚拟机实例数据,网络数据等。
  • 工作过程
    1. 用户输入命令,api 会查看这种类型的 instance 是否达到最大值,给 scheduler 发送一个
      消息(实际上是发送到 Queue 中)去运行这个实例。
    2. 调度器接收到了消息队列 Queue 中 API 发来的消息,然后根据事先设定好的调度规则,选择好一个 host,之后,这个 instance 会在这个 host 上创建。
    3. 真正创建 instance 是由 compute 完成的,通过 glance 查找镜像。
    4. 根据找到的镜像,到 database 中查找相应的数据
    5. volume 创建虚拟机实例的卷
    6. network 为虚拟机分配 IP 等网络资源

5.6 Keystone权限控制过程是什么?

用户传 credential 给 keynote 进行请求,keynote 进行认证以后分配给用户一个 token(令牌),用户获得权限,将令牌和虚拟机请求传给 nova,nova 向 keynote 验证令牌,获得权限后连同对镜像的请求传给 glance,glance 向 keynote 验证令牌,把镜像传给 nova;nova 再将用户接入网络的请求传给 quantum,验证成功后,即传出成功访问的回答。

5.7 Quantum原理是什么?

5.8 Cinder存储的机制是什么?

  • 块存储Cinder
    • 块存储单元“卷”
    • 多个卷可以挂载到同一个虚机
    • 卷可以在虚机间移动
    • 同一个卷同一个时间只能被挂载的一个虚机实例
    • 块存储管理:块设备到虚机的创建,挂载和卸载
  • Cinder架构
    • API:接受REST请求并放入队列
    • Schedule:卷的分配
      • H版采用simple分配策略,即选择卷数量最少的活跃节点
    • Volume service管理存储空间

5.9 Swift的核心概念有哪些?

  • object:对象。基本的存储实体,所有数据按照对象进行存储
  • container:容器。对象的装载体,组织数据的方式,存储的隔间,类似于文件夹,但不能嵌套
  • account:账户。权限单位,一个 account 拥有若干 container

5.10 Swift的组件有哪些,都有什么作用?

  • Proxy Server :是提供 Swift API 的服务器进程,负责 Swift 其余组件间的相互通信。对于每个客户端的请求,它将在 Ring 中查询 Account、Container 或 Object 的位置,并且相应地转发请求
  • Storage Server :提供了磁盘设备上的存储服务
  • Consistency Servers :查找并解决由数据损坏和硬件故障引起的错误
  • Ring:Swift 最重要的组件,用于记录存储对象与物理位置间的映射关系

6. 云存储

6.1 大规模数据存储面临的新问题与挑战

  • 传统模式的挑战——核心问题是数据量与成本的矛盾
    • 成本:处理能力扩充、人力等
    • 效率:从降低的量变到不可用的质变
    • 变更:业务逻辑
    • 数据库的限制:表结构
    • 其他:易用性、可靠性、安全性

6.2 索引技术

  • 二叉搜索树BST:小左大右,可能形成不同的树
  • B树:多路平衡搜索树,变种:红黑树、B+树、B*树等等
  • B+树:降低非叶子节点大小,提高查找效率,支持随机查询和顺序查询
  • B*树:中间节点(非根非叶子)增加指向兄弟的指针
  • 数据库索引:位图索引,全文索引,散列索引
  • 空间数据:R树

6.3 GFS体系结构

  • 中心服务器模式:一个 GFS 集群由一个 master 和大量的 chunkserver 构成,并被许多客户(Client)访问。通过单个 master 来协调数据访问、元数据存储,掌握 chunkserver 情况,方便负载均衡。客户与 master 的交换只限于对元数据(metadata)的操作,所有数据方面的通信都直接和 chunkserver 联系
  • 文件被分成固定大小的块。每个块有一个不变的、全局唯一的标识,是在块创建时由 master 分配的。每个数据块至少在 3 个数据块服务器上冗余,提高可靠性
  • 不缓存数据:采用流式读写,chunkserver 上的数据存储使用本地文件系统
  • 在用户态下实现,提供专用的访问接口

6.4 GFS的容错机制

  • Master容错:命名空间(目录结构)以及 chunk 与文件名的映射通过日志容错,chunk 副本位置信息存储于 chunk server ,master 故障时可恢复
  • ChunkServer容错——副本方式:每个 chunk 有多个存储副本,存储于不同的服务器上;每个 chunk 分为若干 block,对应一个 32bit 校验码

6.5 NoSQL相较于传统数据库的特点

6.6 常见的NoSQL数据类型和代表产品

  • 键值KV型:Redis
  • 列存储数据库:HBase
  • 文档型数据库:MongoDb
  • 图形数据库:Neo4j

详细见下表:

6.7 Bigtable,Redis,MongoDB,Neo4j的数据模型、存储方式、Partitioning和元数据、事务语义等

  • Bigtable
    • 分布式多维映射表
    • 通过行关键字+列关键字+时间戳进行索引
    • Bigtable对存储的数据不做解析,看做字符串
    • 具体数据结构实现需要用户自行处理
    • 存储逻辑:(row:string, column:string, time:int64)→string
  • Redis
    • 数据存储格式:string(字符串),list(双向链表),set(无序集合),zset(有序集合),hash(hash表)
    • 持久化机制:snapshot,语句追加aof
  • MongoDB
    • 采用二进制JSON(BSON)方式
    • 文档-对象存储
    • 采用类似SQL语句操作
    • 支持“嵌套”
    • 支持分片
    • B-树索引
  • Neo4j
    • 擅长基于关系的查询
    • 查找路径
    • 找邻居节点

6.8 云存储应用的特点

  • 通用的设备支持(云存储的浏览端)
  • 数据同步与共享
  • 任意格式/大小文件
  • 免费+付费

7. 分布式计算技术1

7.1 Mapreduce算法的架构

MapReduce是一种处理海量数据的并行编程模式

  • 用于大规模数据集(通常大于1TB)的并行运算
  • MapReduce实现了Map和Reduce两个功能
    • Map把一个函数应用于集合中的所有成员,然后返回一个基于这个处理的结果集
    • Reduce对结果集进行分类和归纳
    • Map()和 Reduce() 两个函数可能会并行运行,即使不是在同一的系统的同一时刻

7.2 Mapreduce算法设计思想

7.3 Mapreduce三个算例

  • 单词记数问题(Word Count)
    • Step 1: 自动对文本进行分割
    • Step 2:在分割之后的每一对<key,value>进行用户定义的Map进行处理,再生成新的<key,value>对
    • Step 3:对输出的结果集归拢、排序(系统自动完成)
    • Step 4:通过Reduce操作生成最后结果
Step 1: 自动对文本进行分割
Step 2:在分割之后的每一对<key,value>进行用户定义的Map进行处理,再生成新的<key,value>对
Step 3:对输出的结果集归拢、排序(系统自动完成)
Step 4:通过Reduce操作生成最后结果
  • 词频统计
    • 如何计算词频?


    • Count(A, B)容易计算(wordcount)
    • 关键问题在于mapreduce的同时也计算出Count(A) :增加词对(a, *)


    • 统计词频
      • 在mapper中增加(a, *)
      • 通过partitioner将所有a的送到同一个reducer
      • 通过排序将(a, *) 排在第一位
      • 增加计算P(x|a)
  • 倒排索引
    • 每个文件中有若干词——可以建立文件-词的索引 ,倒排索引——词-文件
    • 实现:



      注意图中的错误,map结果是key-value形式,图中缺少value的1

  • 相似度比较
    • 倒排索引-计算文章相似性(两两相似)-统计文章相似度
    • step1


    • step2


    • step3 各种统计算法、阈值

7.4 运用mapreduce算法解决实际问题

写MapReduce的技巧

  • 将计算最终结果所需内容设置为<KEY,VALUE>组合
  • 根据实际情况分配哪些归为KEY,哪些归为VALUE
  • Map:生成<KEY,VALUE>对,分配依据为KEY或者KEY的一部分
  • Combiner:Map结果的合并,减少单个Map传递给单个Reduce的中间结果的重复
  • Partition:分发策略,reduce计算所需所有内容需要分配到一个节点
  • Reduce:计算得到最终结果

7.5 如何使用mapreduce进行排序

Hadoop中内部Map和Reduce两个阶段所做的排序,可以使用下图来说明。



对于key值的排序,其实是在Map阶段进行的,而Reduce阶段所做的工作是对各个Map任务的结果进行Merge工作,这样就能保证整体是有序的。如果想在使用多个Reduce任务的情况下保证结果有序,我们可以做的是在上图中的partition阶段进行控制,使分配到每个reduce task的数据块为数值区域独立的,即比如整体数据在0~50之间,划分为5个Reduce任务的话,可以0~10区间的数据到第一个Reduce Task,10~20之间的到第二个,以此类推。但是这样就存在一个问题,划分出的各个任务中的数据可能并不是均等的,这样某些Reduce Task处理了很多数据,而其他的处理了很少的数据。Hadoop提供了RandomSampler类(位于InputSampler类中)来进行随机取样,然后按照取样结果对值域进行划分。

7.6 算法调优

  • 更加优化的key-value对设置
  • Map算法 :Key-value对生成
  • Combiner算法:自定义combiner ,对key的解析,对value的解析 ,对value的计算
  • Partition算法 : 控制分发策略,原则上按照key分发,如果key是多元key,需要对key进行解析之后分发
  • Reduce算法:对key的解析, 对value的解析,对value的计算
  • Mapreduce在hadoop中的执行过程
    • Map:从磁盘上读数据-执行map函数-Combine结果-将结果写到本地磁盘上
      • 将结果写到本地磁盘上 :map阶段产生的中间结果要写到磁盘上,提高系统的可靠性,代价是降低了系统的性能
    • Reduce:从各个map task的磁盘上读相应的数据(shuffle)-排序sort-执行reduce函数-将结果写回HDFS
      • 从各个map task的磁盘上读相应的数据(shuffle):采用HTTP协议从各个map task上远程拷贝结果
      • Mapreduce确保每个reducer的输入都按键排序,系统执行排序的过程——将map输出作为输入传给reduer——称为shuffle,是调优的重点

7.7 Mapreduce运行过程中的各种参数及其作用

  • Map参数
    • Map函数开始产生输出时,并不是直接写入磁盘,首先通过缓冲方式写入内存,并进行预排序
      • 缓冲区大小io.sort.mb,默认100MB
      • 缓冲区容量阈值:io.sort.spill.percent,默认0.80
      • 缓冲区达到阈值后写入mapred.local.dir指定路径
      • 当缓冲区被填满,map会阻塞直到写过程完成
    • 在写磁盘之前,线程根据最终要传送到的reducer对数据进行partition,每个partition内数据按照key进行键内排序,如果有combiner,则在排序后的输出上运行
      • 任务完成前,多溢出写文件需要合并进行分区和排序,一次最多合并流数:io.sort.factor,默认10
      • 如果指定combiner,溢出写次数最小值:min.num.spills.for.combine,默认3,被满足时,combiner在输出文件写到磁盘之前运行
    • 写磁盘时如果压缩map输出则效率更高
      • 压缩标志:mapred.compress.map.output,默认false
      • 压缩方式:mapred.map.output.compression.codec,默认org.apache.hadoop.io.compress.DefaultCodec
    • Reducer通过HTTP方式从map处得到输出文件的分区,文件分区的工作线程数由tasktracker控制,而不属于哪一个具体的map任务
      • Tasktracker的工作线程数:tracker.http.threads,默认40
  • Reduce参数
    • Reduce任务交给JVM处理
      • JVM内存大小:mapred.child.java.opts
    • Map输出文件位于运行map任务的tasktracker的本地磁盘,reduce任务需要集群上若干map任务的输出作为输入,每个map任务完成时间可能不同,因此只要有一个map任务完成,reduce任务就开始复制其输出
      • reduce任务复制线程:mapred.reduce.parallel.copies,默认5
      • Reduce获取一个map输出最大时间:mapred.reduce.copy.backoff,默认300s,在声明失败之前,如果超时,可以尝试重传
    • 如果map输出很小,则复制到reduce的tasktracker的内存中,否则则先写入内存缓冲区,当超过缓冲区溢出阈值,或达到map输出阈值时,再合并后溢出写到磁盘中
      • Map输出内存缓冲区占堆空间的百分比:mapred.job.shuffle.input.buffer.percent,默认0.70
      • 缓冲区溢出阈值:mapred.job.shuffle.merge.percent,默认0.66
      • Map输出阈值:mapred.inmem.merge.threshold,默认1000
    • 随着磁盘上的副本的增多,后台线程会根据合并因子将它们合并成更大的排好序的文件,压缩的map输出都在内存中解压缩
      • 合并因子:io.sort.factor,默认10
    • 从map处获取数据之后,则开始reduce过程,reduce开始时,内存中map输出大小不能超过输入内存阈值,以便为reduce提供尽可能多的内存,如果reduce需要内存较少,可以增加此值来减少访问磁盘次数
      • 输入内存阈值:mapred.job.reduce.input.buffer.percent,默认0.0
    • Reduce的输出结果直接写入HDFS系统
      • Hadoop文件缓冲区:io.file.buffer.size,默认4KB

7.8 参数调优

  • 调优原则
    • 给shuffle过程尽可能多的内存空间
    • Map和reduce函数尽量少用内存
    • 运行map和reduce任务的JVM的内存尽量大
    • Map端尽量估算map输出的大小,减少溢出写磁盘的次数
    • Reduce端的中间数据尽可能的多驻留在内存
    • 增加Hadoop的文件缓冲区

8. 分布式计算技术2

8.1 流式计算与批量计算的区别

核心区别:实时性,来一个处理一个

流式计算与批量计算的区别

8.2 流式计算的关键要素

  • 处理速度与数据到来速度的匹配
  • 保障数据的顺利流动
  • 处理逻辑的表示

8.3 数据分发机制

  • 随机分发/发牌式分发
  • 按特定值分发
  • 广播分发(每个包会分发给所有的节点)

8.4 运用流式计算方法解决实际问题

一些技巧:

  • 增加功能相同的节点,使用随机分发
  • 将处理功能分散,使用特定值分发
  • 增加前序节点,在处理前对数据进行某种转换
  • 某些节点可以作为专门的数据转发节点,使用广播分发发给后续节点
  • 某些节点可以作为同步节点,同时接收到来自多个上游的数据后触发下一个步骤

8.5 图的切分方式

边切分(Edge-Cut)和点切分(Vertex-Cut)

8.6 BSP计算模式

BSP模式

  • 概述
    • Bulk Synchronous Parallell整体同步并行
    • 将计算分成一系列的超步(superstep)的迭代(iteration)
    • 纵向上看是一个串行模式,一轮一轮顺序化串行
    • 横向上看是一个并行的模式
    • 每两个superstep之间设置一个栅栏(barrier)
    • 栅栏——整体同步点
    • 确定所有并行的计算都完成后再启动下一轮superstep


  • 本地计算阶段:每一个processor进行本地计算
  • 全局通信阶段:每一个processor计算完毕后,将消息传递个与之关联的其它processors
  • 栅栏同步阶段:所有的计算和消息传递都进行完毕后,进入下一个superstep

8.7 运用图数据计算方法解决实际问题

如最短路径计算——Dijkstra(过程见第8讲课件P45-52)

9. 分布式处理框架

9.1 Hadoop项目的由来

起源于一个开源的网络搜索引擎项目 Apache Nutch ,借鉴 GFS,实现了一个开源的实现 HDFS,05 年 nutch 上实现了一个 mapreduce 系统,完成了所有主要算法的 mapreduce+HDFS 移植。MapReduce+HDFS 从 nutch 移植出来构成了 Hadoop。

9.2 HDFS的体系结构

  • MapReduce——分布式数据处理模型和执行环境
  • HDFS——分布式文件系统
  • HBase——分布式、按列存储数据库
  • ZooKeeper——分布式、可用性高的协调服务
  • Pig——数据流语言和运行环境,用于检索非常大的数据集
  • Hive——分布式、按列存储的数据仓库

9.3 HDFS的运行机制

  • 可靠性保障
    • 一个namenode和多个datanode
    • 数据复制(冗余机制)
      • 存放的位置(机架感知策略)
    • 故障检测
      • Datanode :心跳包(检测是否宕机),块报告(安全模式下检测),数据完整性检测(校验和比较)
      • Namenode:日志文件,镜像文件
  • 读文件流程
    1. 客户端调用DistributedFileSystem对象的open()方法
    2. .DistributedFileSystem通过RPC联系namenode,得到所有数据块信息,对每个数据块,namenode返回存有该块副本的datanode地址,并且这些datanode根据他们与客户端的距离进行排序
    3. DistributedFileSystem类返回一个FSDataInputStream对象给客户端并读取数据
    4. 客户端对该对象调用read()方法读取数据
    5. FSDataInputStream连接距离最近的datanode读取数据,数据读取完毕时FSDataInputStream会关闭与该datanode的连接,然后寻找下一个块的datanode
    6. FSDataInputStream可能并行读取多个datanode,当客户端完成读取时,对FSDataInputStream调用close()方法
    7. FSDataInputStream从datanode读取数据时如果遇到错误,会尝试从该块的另外一个最近的datanode读取数据,并记住故障datanode保证以后不会继续从该节点读取其他块
    8. 每个读取的块通过校验和确认以保证数据完整
    9. 如果FSDataInputStream发现一个损坏的块,则在从其他datanode读取块之前通知namenode
  • 写文件流程
    1. 客户端调用DistributedFileSystem对象的create()方法创建文件
    2. DistributedFileSystem通过RPC联系namenode,namenode执行各种检查确保待建立的文件不存在,且客户端拥有创建该文件的权限
    3. 如果检查通过,namenode为新文件创建一条记录,否则抛出一个IOException异常
    4. DistributedFileSystem给客户端返回一个FSDataOutputStream对象进行写数据
    5. FSDataOutputStream将待写入数据分成数据包并写入内部队列dataqueue
    6. DataStreamer处理dataqueue,根据datanode列表要求namenode分配适合的新块来存储数据备份
    7. namenode分配的数据备份datanode(通常3个)形成一个管线,DataStreamer将数据包传输给管线中的第一个节点,然后该节点存储完之后发送给第二个节点,以此类推
    8. FSDataOutputStream维护一个确认队列ackqueue,当收到管线中所有datanode的确认后,该数据包从确认队列中删除
    9. 如果datanode发生故障,则关闭管线,将确认队列中的数据包添加回数据队列的最前端,将故障的数据块和datanode信息返回给namenode以便该datanode恢复后删除错误数据块,从管线中删除错误节点,并把剩余数据块写入正常datanode
    10. 如果复本数量不足,则namenode根据datanode分配新的datanode并创建新的复本,该datanode被加入管线继续正常存储

9.4 Hadoop中MapReduce的实现机制

见课件第9讲P24-51

9.5 Htable的数据结构

HTable一些基本概念

  • Row key:行主键, HBase不支持条件查询和Order by等查询,读取记录只能按Row key(及其range)或全表扫描,因此Row key需要根据业务来设计以利用其存储排序特性(Table按Row key字典序排序如1,10,100,11,2)提高性能。
  • Column Family(列族):在表创建时声明,每个Column Family为一个存储单元。在上例中设计了一个HBase表blog,该表有两个列族:article和author。
  • Column(列):HBase的每个列都属于一个列族,以列族名为前缀,如列article:title和article:content属于article列族,author:name和author:nickname属于author列族。
    Column不用创建表时定义即可以动态新增,同一Column Family的Columns会群聚在一个存储单元上,并依Column key排序,因此设计时应将具有相同I/O特性的Column设计在一个Column Family上以提高性能。
  • Timestamp:HBase通过row和column确定一份数据,这份数据的值可能有多个版本,不同版本的值按照时间倒序排序,即最新的数据排在最前面,查询时默认返回最新版本。如上例中row key=1的author:nickname值有两个版本,分别为1317180070811对应的“一叶渡江”和1317180718830对应的“yedu”(对应到实际业务可以理解为在某时刻修改了nickname为yedu,但旧值仍然存在)。Timestamp默认为系统当前时间(精确到毫秒),也可以在写入数据时指定该值。
  • Value:每个值通过4个键唯一索引,tableName+RowKey+ColumnKey+Timestamp=>value,例如上例中{tableName=’blog’,RowKey=’1’,ColumnName=’author:nickname’,Timestamp=’ 1317180718830’}索引到的唯一值是“yedu”。
  • 存储类型:
    • TableName 是字符串
    • RowKey 和 ColumnName 是二进制值(Java 类型 byte[])
    • Timestamp 是一个 64 位整数(Java 类型 long)
    • value 是一个字节数组(Java类型 byte[])

可将HTable的存储结构理解为下图,即HTable按Row key自动排序,每个Row包含任意数量个Columns,Columns之间按Column key自动排序,每个Column包含任意数量个Values。理解该存储结构将有助于查询结果的迭代。

9.6 Hbase的运行机制

数据存储实体为区域,表按照水平的方式划分为一个或多个区域,每个区域有一个随机 id,
且区域内行为键值有序的。区域以分布式方式存储在集群内。通过区域服务器运行:

  1. 写:写数据首先写入“预写日志”;先缓存,再批量写入;完成后在日志中做标记
  2. 读:区域服务器先在缓存中查找,找到则直接服务;
  3. 合并:映射文件数量超过阈值,则区域服务器进行合并
  4. 分割:区域文件大过阈值时,按照行方式对半分割;在元信息表中生成子元信息表;主服务器在得知分割后,将子表分配给新的区域服务器服务
  5. 失效恢复:将失效服务器的区域分配给其他服务器,原“预写”日志进行分割并分配给新的区域服务器

9.7 Yarn对Hadoop的核心改进

  1. 原 框 架 中 的 JobTracker 和 TaskTracker 被 ResourceManager,ApplicationMaster与NodeManager 取代。
  2. ResourceManager是一个中心的服务,它做的事情是调度、启动每一个Job所属的 ApplicationMaster、另外监控 ApplicationMaster的存在情况。
  3. NodeManager功能比较专一,就是负责Container状态的维护,并向RM保持心跳
  4. ApplicationMaster负责一个Job生命周期内的所有工作,类似老的框架中JobTracker。可以运行在resourceManager以外的机器上

改进后的优点:

  1. 减少了jobTracker也即resourceManager的资源消耗,让监测每一个Job子任务(tasks)状态的程序分布式化
  2. ApplicationMaster是一个可变更的部分,用户可以对不同的编程模型写自己的AppMst,让更多类型的编程模型能够跑在Hadoop集群
  3. 对于资源的表示以内存为单位,比以task任务数目分配更加合理
  4. 客户端调用API或者接口,程序框架改变后不再需要被强制更新

9.8 Spark架构及运行机制

  • Spark架构
    • Spark架构使用了分布式计算中master-slave模型,master是集群中含有master进程的节点,slave是集群中含有worker进程的节点
    • master作为整个集群的控制器,负责整个集群的正常运行
    • worker相当于计算节点,接受主节点命令与状态汇报
    • executor负责任务的执行
    • client作为用户的客户端负责提交应用
    • driver负责控制一个应用的执行
  • 运行机制
    • Spark集群部署后,需要在主节点和从节点分别启动master进程和worker进程来控制集群。在一个应用执行中,driver是应用逻辑执行的起点,负责作业的调度,即Task任务的分发,而多个worker用来管理计算节点和创建executor并行处理任务。在执行阶段,driver会将task和其依赖的文件传递给worker机器,同时executor对相应数据分区的任务进行处理。
    • SparkContext: 整个应用的上下文,控制应用的生命周期。
    • RDD: Spark的基本计算单元,一组RDD可执行的有向无环图RDD Graph。
    • DAGScheduler: 根据作业构建基于Stage的DAG,并提交给Stage的TaskScheduler。
    • TaskScheduler: 将任务分给executor执行。
    • SparkEnv: 线程级别的上下文,存储运行时的重要组件的引用。
    • 运行流程:Client提交应用,master找到一个worker启动driver,driver向master请求资源,之后将应用转化为RDD Graph,再由DAGScheduler将RDD Graph转换为stage的DAG提交给TaskScheduler,由TaskScheduler提交任务给executor。
Spark架构

9.9 Storm架构及运行机制

  • Storm是一个分布式流处理&&实时的计算系统
  • 架构
    • Storm采用Master/Slave体系结构,分布式计算由Nimbus(主节点)和Supervisor(工作节点)两类服务进程实现,Nimbus进程运行在集群的主节点,负责响应集群节点,分配任务和故障检测 ,Supervisor运行在集群的从节点,负责收听工作指派,运行工作进程。 Nimbus和Supervisors之间所有的协调工作是通过一个Zookeeper集群实现。
    • Storm实现了一种数据流模型,其中数据持续地流经一个转换实体网络。一个数据流的抽象称为一个流(stream),这是一个无限的元组序列。每个流由一个唯一ID定义,这个ID可用于构建数据源和接收器(sink)的拓扑结构。流起源于喷嘴(spout),Spout将数据从外部来源流入 Storm 拓扑结构中。接收器(或提供转换的实体)称为螺栓(bolt)。螺栓实现了一个流上的单一转换和一个 Storm 拓扑结构中的所有处理。Bolt既可实现 MapReduce之类的传统功能,也可实现更复杂的操作(单步功能),比如过滤、聚合或与数据库等外部实体通信。典型的 Storm 拓扑结构会实现多个转换,因此需要多个具有独立元组流的Bolt。Bolt和Spout都实现为Linux系统中的一个或多个任务。
    • 拓扑topology:Storm中运行的一个应用是一个拓扑(对应Hadoop里的job)
Storm架构

Storm喷嘴spout和螺栓bolt模型
  • 程序执行过程


9.10 Kafka架构及运行机制

http://blog.csdn.net/suifeng3051/article/details/48053965

  • 消息传递机制
    • Producer通过push方式向kafka发布消息
    • Consumer通过pull方式从kafka获取消息
  • 消息管理基本概念
    • Topic:消息类别。物理上不同topic的消息分开存储,逻辑上一个topic的消息虽然保存于一个或多个broker上但用户只需指定消息的topic即可生产或消费数据而不必关心数据存于何处
    • Partition:每个topic包含一个或多个partition,创建topic时可指定parition数量。每个partition对应于一个文件夹,该文件夹下存储该partition的数据和索引文件
    • Consumer Group:每个consumer属于一个特定的group(可为每个consumer指定group name,若不指定group name则属于默认的group)。同一topic的一条消息只能被同一个group内的一个consumer消费,但多个consumer group可同时消费这一消息。
  • 消息发布机制
    • Producer指定发布的topic
    • Topic里的信息物理上分为多个partition存储
    • Broker存储若干topic的partition,允许同topic的不同partition存储在不同的broker上
    • 由zookeeper统一管理
    • Producer可以通过指定消息的key控制将消息发到某个partition
  • 消息消费机制
    • Consumer需要指定消费的Topic
    • Consumer需要指定隶属的consumer group
    • 一个Topic里的每条信息只能被consumer group中的一个consumer消费,属于不同consumer group的consumer可以共同消费一个topic的相同信息
    • Consumer group里的consumer和topic的partition按照id顺序进行消费,例如0/1/2consumer分别消费0、3/1、4/2号partition,如果partition数比consumer数少,则id数超过partition数的consumer无法获取数据
  • 消息存储机制
    • 消息在partition上顺序写磁盘,通过偏移量访问
    • 消息被持久化,消息被访问过后不删除
    • 通过配置保存时长和Partition文件大小控制删除
  • Kafka的发布-订阅特点
    • 增加了partition和consumer group概念
    • Partition能够增加消息发布效率:相当于把topic的存储机器分布式化,避免单一机器速度过慢导致性能受限
    • Consumer group能够增加消息消费效率:相当于把topic的消费者分布式化,避免单一消费者过慢导致性能受限

9.11 Pregel架构及运行机制

Pregel:大规模分布式图计算平台

  • 主从结构
  • 一主多从
  • 切边法分割子图
  • 主节点负责管理工作,不参与具体计算
  • 从节点负责每步的计算
  • 从节点间相互传递消息

Pregel采用了“主从结构”来实现整体功能,图14-15是其架构图,其中一台服务器充当“主控服务器”,负责整个图结构的任务切分,采用“切边法”将其切割成子图(Hash(ID)=ID mod n ,n是工作服务器个数),并把任务分配给众多的“工作服务器”,“主控服务器”命令“工作服务器”进行每一个超级步的计算,并进行障碍点同步和收集计算结果。“主控服务器”只进行系统管理工作,不负责具体的图计算。

每台“工作服务器”负责维护分配给自己的子图节点和边的状态信息,在运算的最初阶段,将所有的图节点状态置为活跃状态,对于目前处于活跃状态的节点依次调用用户定义函数F(Vertex)。需要说明的是,所有的数据都是加载到内存进行计算的。除此之外,“工作服务器”还管理本机子图和其他“工作服务器”所维护子图之间的通信工作。

在后续的计算过程中,“主控服务器”通过命令通知“工作服务器”开始一轮超级步的运算,“工作服务器”依次对活跃节点调用F(Vertex),当所有的活跃节点运算完毕,“工作服务器”通知“主控服务器”本轮计算结束后剩余的活跃节点数,直到所有的图节点都处于非活跃状态为止,计算到此结束。

Pregel采用“检查点”(CheckPoint)作为其容错机制。在超级步开始前,“主控服务器”可以命令“工作服务器”将其负责的数据分片内容写入存储点,内容包括节点值、边值以及节点对应的消息。

“主控服务器”通过心跳监测的方式监控“工作服务器”的状态,当某台“工作服务器”发生故障时,“主控服务器”将其负责的对应数据分片重新分配给其他“工作服务器”,接收重新计算任务的“工作服务器”从存储点读出对应数据分片的最近“检查点”以恢复工作,“检查点”所处的超级步可能比现在系统所处的超级步慢若干步,此时,所有的“工作服务器”回退到与“检查点”一致的超级步重新开始计算。

从上述描述可以看出,Pregel是一个消息驱动的、遵循以图节点为中心的编程模型的同步图计算框架。考虑到“主控服务器”的功能独特性和物理唯一性,很明显,Pregel存在单点失效的可能。

9.12 各种分布式处理框架的异同点

10. 控制策略与保障技术

10.1 分布式处理的不一致情况有哪些

10.2 有哪些原因造成了分布式处理的不一致

硬件损坏,节点掉线,网络延迟等

10.3 quorum protocol是什么

  • W+R>N
  • W>N/2
  • N=number of nodes that store data
  • W=number of successful WRITEs in a PUT request
  • R=number of successful READs in a GET request
  • 理解为“真理掌握在多数人手中”

10.4 主从机制下主和从的任务特点是什么

  • 对于分布式文件系统、计算框架等来说,主节点负责管理、从节点负责具体业务
    • 主节点:元数据,调度和任务分配 ,整体管理,容错(备份+日志(快照+AOF))
    • 从节点:具体业务执行,容错(主节点调度)
    • 心跳机制: 主节点了解从节点状况
  • 对于数据库主从架构来说,主节点负责核心业务,从节点分流
    • 单一库负载压力过大
    • 多个库来分摊
    • 写库的分摊
      • 将数据分摊到多个库
      • 就同一数据而言,通常仍然只有一个库负责写
    • 读库的分摊
      • 同一数据复制多份到多个库
      • 同步是核心问题
    • 适用于读多写少的应用场景
    • 就单一数据而言,一写多读:读写分离策略

10.5 数据库主从机制有哪些

半同步复制、中间件控制、缓存策略

10.6 Ring算法是什么,有哪些改进

Ring算法:


改进:引入虚拟节点。当节点个数发生变化时,只需调整节点与虚节点的映射。

10.7 Zookeeper的实现机制是什么

http://www.cnblogs.com/lpshou/archive/2013/06/14/3136904.html

  • ZooKeeper提供通用的分布式锁服务,用以协调分布式应用,适用于主要负载为读的应用场合
  • Zookeeper架构
    • ZooKeeper是一个由多个Server组成的集群
    • 一个Leader,多个Follower
      • 每个Server都保存了一份数据副本
      • 全局数据一致
      • 分布式读写
      • Leader负责写和同步,follower负责读
      • 更新请求转发,由Leader实施
  • Zookeeper使用
    • 独占锁:如果分布式应用需要对某资源独占使用,可以申请独占锁,有且仅有一个Client可以获取到独占锁
    • 共享锁:如果之前没有独占锁,就可以获取共享锁
  • 使用ZooKeeper的约定
    • 更新请求顺序执行:来自同一个Client的更新请求按其发送顺序依次执行
    • 数据更新原子性:一次数据更新要么成功,要么失败。不存在部分数据写入成功或失
      败的情况
    • 全局唯一数据视图: Client无论连接哪个Server,数据视图都是一致的
    • 实时性:在一定时间范围内,Client能读到最新数据

10.8 Paxos过程是什么

  • Phase1.准备阶段:
    • (a)proposer 选择一个提案编号 n 并将 prepare 请求发送给 acceptors 中的一个多数派;
    • (b)acceptor 收到 prepare 消息后,如果提案的编号大于它已经回复的所有 prepare 消息,则 acceptor 将自己上次的批准回复给 proposer,并承诺不再批准小于 n 的提案;
  • Phase2. 批准阶段:
    • (a)当一个 proposor 收到了多数 acceptors 对 prepare 的回复后,就进入批准阶段。它要向回复 prepare 请求的acceptors 发送 accept 请求,包括编号 n 和根据 P2c 决定的 value(如果根据 P2c 没有决定 value,那么它可以自由决定 value)。
    • (b)在不违背自己向其他 proposer 的承诺的前提下,acceptor 收到 accept 请求后即批准这个请求。
  • 这个过程在任何时候中断都可以保证正确性.例如如果一个 proposer 发现已经有其他 proposers 提出了编号更高的提案,则有必要中断这个过程。 因此为了优化,在上述 prepare 过程中,如果一个 acceptor 发现存在一个更高编号的"草案",则需要通知 proposer,提醒其中断这次提案。
  • Paxos选举关键
    • 决议(value)只有在被 proposers 提出后才能被批准,未经批准的决议称为“提案(proposal)”
    • 在一次 Paxos 算法的执行实例中,只批准(chosen)一个 value
    • learners 只能获得被批准(chosen)的 value
    • 一致性提案编号!

10.9 时间片机制有什么用,chubby释放和重连机制是什么

时间片通信协议是一种倒计时“租期”系统,实现对操作授权的“限时”。

10.10 多租户的概念是什么

多租户技术(multi-tenancy technology)或称多重租赁技术,是一种软件架构技术,它是在探讨与实现如何于多用户的环境下共用相同的系统或程序组件,并且仍可确保各用户间数据的隔离性。

  • 在多租户技术中,租户(tenant)是指使用系统或电脑运算资源的客户,但在多租户技术中,租户主要对应其所使用的基于供应商所开发或建置的应用系统或运算资源
  • 应用系统会容纳数个以上的用户在同一个环境下使用,为了要让用户使用如同单独使用一个环境一样,则应用程序与运算环境必须要特别设计
  • 除了可以让系统平台可以允许同时让多份相同的应用程序运行外,保护租户数据的隐私与安全也是多租户技术的关键之一

11. 高级话题与业界动态

11.1 什么是云安全

有两种理解:

  1. 利用云的强大计算、存储能力进行安全保障,包括安全云和云查杀木马病毒的特征越来越细,识别对存储和计算要求越来越高,利用云进行计算
  2. 云的安全保障
    数据放在云端,操作通过网络,通过一定机制保障云是安全的

11.2 云计算的安全威胁

  • 共享技术漏洞
  • 数据丢失与数据泄露
  • 恶意内部用户
  • 账户服务与传输劫持
  • 不安全的 APIs
  • 服务的恶意使用
  • 不确定风险预测

11.3 云计算的安全优势

  1. 数据可访问性大大提高
  2. 分布式存储:实现数据的备份和容错机制
  3. 数据高度安全:数据在云端集中存储实现专业的数据保护和备份,更容易实现安全监测
  4. 事件快速反应

11.4 物联网与云计算的关系

  1. 物联网指的是将各种信息传感设备与互联网结合起来而形成一个巨大网络。其目的是让所有的物品与网络连接在一起,方便识别和管理。在这个整合的网络中,存在能力超级强大的中心计算机群,能够对整合网络中的人员、机器、设备和基础设施实施实时的管理和控制。具有三个特点:全面感知;可靠传送;智能控制
  2. 物联网和云计算之间是应用与平台的关系。物联网的发展依赖于云计算系统的完善,从而为海量物联信息的处理和整合提供可能的平台条件,云计算的集中数据处理和管理能力将有效的解决海量物联信息存储和处理问题。

11.5 什么是主机,什么是终端

  • 云主机:新一代的共享主机:主机公司将它的硬件和网络线路,做成一朵云,向客户提供一些通向这朵云的网络接口API,供其使用。每个用户共享的不是某一台特定的服务器,而是云里所有的服务器。
  • 云终端:云的接入终端。核心在云,终端只是云的访问接口

11.6 大型数据中心构建和管理主要需要做哪些事

  • 设计与构建
    • 建筑的设计与构建
      • 选址:通信,电力,地理位置,安全性
      • 建筑要求:规模,布局,高,室内环境—无窗或少窗
    • 基础设施设计与构建
      • 电力布局
      • 网络拓扑结构
      • 环境控制
      • 节能
    • 数据中心上线
      • 选择服务器
      • 选择软件
      • 机器上架
      • 软件部署测试
  • 管理与维护
    • 硬件、软件、数据的管理与维护
    • 资源、安全管理

11.7 云计算中的信任机制如何构建

建立用户使用云计算服务所需要的信任的社会关系,最基本、最重要的保证在于互联网的民主性所形成的由下而上的力量。事实上,信任不是一次性测试出来的,也不是依靠一套固定指标测出来的,它是云计算运作过程中累积出来的品质,是消除一个个不可信要素的过程。如何更好地抽象、应用这种应用演化中所涌现出来的信任,是云安全中信任管理的关键问题之一。云计算中信任的建立、维持和管理,可以通过社会与技术手段相结合的方式来推动信任机制的完善。
云提供者不但要保障网络传输等的安全性,还要加强数据处理和存储时的安全性,防止外部入侵数据的同时防止内部人员的泄露。在存储方面,通过冗余等方法,加强节点的可信度。
总体来讲,在不可信的基础上构建可信的服务。

课程
Web note ad 1