# 云计算期中

# 一、数据中心基础知识

# 1. 云计算的基本概念

# 1.1 定义与演化

云计算是通过网络按需提供可动态伸缩的廉价计算服务

# 1.2 特点

# 1.2.1 七大特点

超大规模
虚拟化
高可靠
通用性
高可伸缩性
按需服务
廉价

# 1.2.2 NIS 云计算五大特征（最官方）

自助服务
- 云计算允许用户根据需要自助申请和管理计算、存储和网络资源，而无需事先与云服务提供商协商或人工干预。
广泛的网络访问
- 云计算通过广泛的网络接入（如互联网、私有网络、虚拟专用网络等）使用户能够从任何地方、任何设备上访问和使用云服务。
资源池化
- 云计算将多个客户的计算、存储和网络资源集中管理和分配，以最大化资源的利用率和效率。
快速弹性伸缩
- 云计算提供弹性计算资源的能力，消费者能方便、快捷地按需获取和释放计算资源，以根据用户的需求进行快速自动化扩展或缩减，以实现高效利用和成本控制。用户可以根据需求快速增加或减少计算资源，而无需等待或付出高昂的费用。
服务度量和优化
- 云计算提供服务度量和优化的能力，以监测和优化资源使用情况和服务质量。用户可以通过各种工具和服务来监控和度量其使用情况，以帮助其进行成本和资源优化。服务提供商也可以通过度量和分析用户的使用情况来优化其服务。
- 消费者使用云端计算资源是要付费的，付费的计量方法有很多，比如根据某类资源（如存储、CPU、内存、网络带宽等）的使用量和时间长短计费，也可以按照每使用一次来计费。但不管如何计费，对消费者来说，价码要清楚，计量方法要明确，而运服务提供商需要监视和控制资源的使用情况，并及时输出各种资源的使用报表，做到供 / 需双方费用结算清清楚楚、明明白白。

云计算的五大特征是什么，你知道吗？ - 知乎 (zhihu.com)

# 1.2.3 四个特征

# 1.3 分类：服务类型

SaaS
- 将软件作为服务
  - 针对性更强，它将某些特定应用软件功能封装成服务
- 通过提供满足最终用户需求的业务，按使用收费
  - 互联网 Web 2.0, 应用企业应用，电信业务
  - 云服务提供商把 IT 系通中的应用软件层作为服务租出去，消费者不用自己安装应用软件，直接使用即可，这进一步降低了云服务消费者的技术门槛。
PaaS
- 将平台作为服务
  - 对资源的抽象层次更进一步，提供用户应用程序运行环境
- 通过将 IT 资源、Web 通用能力、通信能力打包出租给应用开发和运营者，按使用收费
  - 提供应用运行和开发环境，提供应用开发的组件（如：数据库）
  - 云服务提供商把 IT 系统中的平台软件层作为服务租出去，消费者自己开发或者安装程序，并运行程序。
IaaS
- 将基础设施作为服务
  - 将硬件设备等基础资源封装成服务供用户使用
- 出租计算，存储，网络等 IT 资源 (不包括程序，可以理解为出租硬件)
  - 按使用收费，通过规模获取利润
  - 云服务提供商把 IT 系统的基础设施层作为服务租出去，由消费者自己安装操作系统、中间件、数据库和应用程序。
无服务器计算 Serverless
- BaaS：Backend as a Service
- FaaS：Function as a Service

# 1.3.1 无服务计算

[什么是无服务器计算？- 阿里云开发者社区 (aliyun.com)](https://developer.aliyun.com/article/1584047#:~:text = 无服务器计算的核心思想是按需分配计算资源。, 当应用程序的某个部分需要执行时，云服务提供商会动态分配所需的计算资源，执行完毕后这些资源会被释放。开发者只为实际使用的计算资源付费，这与传统的按服务器租用时间收费的模式不同。)

无服务器计算的核心思想是按需分配计算资源。当应用程序的某个部分需要执行时，云服务提供商会动态分配所需的计算资源，执行完毕后这些资源会被释放。开发者只为实际使用的计算资源付费，这与传统的按服务器租用时间收费的模式不同。

当一个事件触发函数时，云服务提供商会分配必要的计算资源来执行该函数。在执行完毕后，这些资源会被释放，开发者只需为函数实际运行的时间和资源消耗付费。

Backend as a Service（BaaS）
- 云服务商提供应用后端的管理和维护，客户只需要聚焦前端应用的开发
- 数据库管理、权限管理、消息推送等等
Function as a Service（FaaS）
- 云服务商提供执行模块化代码片段的环境，客户可以即时编写和更新由事件触发的代码片段
- 按钮点击

# 计算：Lambda
事件驱动的无服务器计算（ServerlessComputing）平台
以响应事件的方式运行代码
自动管理代码运行所需要的资源
支持 Node.js, Python, Java, Go, Ruby 和 C# 等

# 1.3.2 无服务器计算的优点

# 1.4 分类：部署模式

云计算按部署模式大致分为四类：

公有云
私有云
混合云
社区云

# 1.4.1 公有云

云端资源开发给社会公众使用。

云端的所有权、日常管理和操作的主体可以是一个商业组织、学术机构、政府部门或者它们其中的几个联合。

云端可能部署在本地，也可能部署于其他地方，比如中山市民公共云的云端可能就建在中山，也可能建在深圳。

# 1.4.2 私有云

云端资源只给一个单位组织内的用户使用，这是私有云的核心特征。

而云端的所有权、日程管理和操作的主体到底属于谁并没有严格的规定，可能是本单位，也可能是第三方机构，还可能是二者的联合。

云端可能位于本单位内部，也可能托管在其他地方。

# 1.4.3 混合云

混合云是云计算的一种类型，它将本地基础结构（或私有云）与公有云结合在一起。使用混合云，可以在两种环境之间移动数据和应用。

混合云由两个或两个以上不同类型的云（私有云、社区云、公共云）组成，它们各自独立，但用标准的或专有的技术将它们组合起点，而这些技术能实现云之间的数据和应用程序的平滑流转。

由多个相同类型的云组合在一起，混合云属于多云的一种。私有云和公共云构成的混合云是目前最流行的 —— 当私有云资源短暂性需求过大（称为云爆发，Cloud Bursting）时，自动租赁公共云资源来平抑私有云资源的需求峰值。例如，网店在节假日期间点击量巨大，这时就会临时使用公共云资源的应急。

# 1.4.4 社区云

** 社区云是由一个特定社区独占使用，该社区由具有共同关切 (如使命、安全要求、政策等) 的多个组织组成。社区云的核心特征是云端资源只给两个或者两个以上的特定单位组织内的员工使用，除此之外的人和机构都无权租赁和使用云端计算资源。** 参与社区云的单位组织具有共同的要求，如云服务模式、安全级别等。具备业务相关性或者隶属关系的单位组织建设社区云的可能性更大一些，因为一方面能降低各自的费用，另一方面能共享信息。

云端资源专门给固定的几个单位内的用户使用，而这些单位对云端具有相同的诉求（如安全要求、云端使命、规章制度、合规性要求等）。

云端的所有权、日常管理的操作的主体可能是本社区内的一个或多个单位，也可能是社区外的第三方机构，还可能是二者的联合。

云端可能部署在本地，也可能部署与他处。

# 1.4.5 总结

公有云 —— 社会公众
私有云 —— 一个单位组织
社区云 —— 两个及以上单位组织
混合云 —— 以上云至少用了两个.

# 1.5 云计算发展现状

云计算的服务类型有哪三种？亚马逊的 AWS 和微软的 Windows Azure 各属于哪一种？
IaaS（基础设施即服务）、PaaS（平台即服务）和 SaaS（软件即服务）。
亚马逊的 AWS 属于 IaaS，Windows Azure 属于 PaaS。

# 1.6 云计算实现机制

SOA 构建层
- 封装云计算能力成标准的 Web Services 服务，并纳入到 SOA 体系
管理中间件层
- 云计算的资源管理，并对众多应用任务进行调度，使资源能够高效、安全地为应用提供服务
- 资源管理
- 任务管理
- 用户管理
- 安全管理
资源池层
- 将大量相同类型的资源构成同构或接近同构的资源池
物理资源层
- 计算机、存储器、网络设施、数据库和软件等

# 1.6.1 管理中间件

# 1.6.2 IaaS 实现机制

# 1.7 数据中心

# 1.7.1 云数据中心的特征

# 1.7.2 云数据中心网络诉求

# 1.7.3 区域和可用区

一个区域覆盖较大的地理范围，通常包含若干个通过私有网络互相连接的、数据冗余的、低延迟的可用区，共同为区域内的用户提供服务

# 1.7.4 数据中心能源效率

$\text{PUE} = \frac{\text{数据中心总能耗}}{\text{IT设备能耗}}$

# 1.8 云计算的核心理念

虚拟化：
提供池化资源和按需服务
多租户
节省开发和维护的成本
数据中心
提供基础设施和安全保障

# 2. 习题

云计算技术（ICT）课后习题答案_云计算技术将计算资源以及其他各类 - CSDN 博客

# 2.1

C）服务运维之可靠性（三个 9、四个 9...） - 知乎 (zhihu.com)

选 A

系统的高可靠性（也称为可用性，英文描述为 HA，High Available）里有个衡量其可靠性的标准 ——X 个 9，这个 X 是代表数字 3~5。X 个 9 表示在系统 1 年时间的使用过程中，系统可以正常使用时间与总时间（1 年）之比，我们通过下面的计算来感受下 X 个 9 在不同级别的可靠性差异。

计算公式

$设X为n个9,time为中断时间\\ time = (1-X)*365*24 \ hours$

常见的数据

1 个 9：(1-90%)*365=36.5 天
2 个 9：(1-99%)*365=3.65 天
3 个 9：(1-99.9%)36524=8.76 小时 **（526 分钟）**
4 个 9：(1-99.99%)36524=0.876 小时 = 52.6 分钟，表示该系统在连续运行 1 年时间里最多可能的业务中断时间是 52.6 分钟。
5 个 9：(1-99.999%)36524*60=5.26 分钟，表示该系统在连续运行 1 年时间里最多可能的业务中断时间是 5.26 分钟。
6 个 9：(1-99.9999%)365246060=31 秒

其实记住 3 个 9 为 526 分钟即可

# 2.2

C) 这句话不正确。

云计算在保障业务连续性方面通常比本地服务更有优势。这是因为云服务提供商通常具备以下能力：

高可用性和弹性：云计算提供商通常会在全球范围内提供数据中心，支持数据的冗余和自动备份，即使某个区域的数据中心出现故障，业务也可以切换到其他区域，保证服务的连续性。
灾备机制：许多云计算服务具备自动的灾难恢复和备份功能，能够帮助企业快速恢复数据和服务，减少宕机时间。
资源弹性扩展：云计算可以根据需求动态分配资源，面对流量突增时可以快速扩展，确保业务的连续性。
专业运维支持：云服务提供商通常会提供全天候的运维监控和支持，及时解决故障，提升业务连续性。

相比之下，本地服务的资源和灾备能力往往有限，可能需要企业自己投入大量成本建设冗余和备份系统，因此在业务连续性方面通常不如云计算灵活和可靠。

# 2.3

# 2.4

正确答案是 C) 向用户提供编写和执行应用程序模块化代码片段的环境。

Backend as a Service（BaaS）
- 云服务商提供应用后端的管理和维护，客户只需要聚焦前端应用的开发
- 数据库管理、权限管理、消息推送等等
Function as a Service（FaaS）
- 云服务商提供执行模块化代码片段的环境，客户可以即时编写和更新由事件触发的代码片段
- 按钮点击

无服务器计算（Serverless Computing） 是一种云计算执行模型，在这种模型下，云服务提供商动态管理服务器资源，用户可以专注于编写和运行代码，而不需要关心服务器的管理、配置或运维。常见的无服务器计算服务如 AWS Lambda、Google Cloud Functions 等。

# 各选项分析

A) 向用户提供不需要基础设施的计算服务
- 该描述不够具体，可以指代多种云计算服务模式，而不仅仅是无服务器计算。无服务器计算不仅是不需要管理基础设施，还特别强调按需执行代码的特性。
B) 向用户提供应用程序服务，用户无需搭建基础设施或者开发应用程序
- 这更符合 SaaS（软件即服务） 的定义，其中应用程序本身由服务商提供，用户无需进行开发，而无服务器计算通常仍需要用户编写代码。
C) 向用户提供编写和执行应用程序模块化代码片段的环境
- 正确。这一描述符合无服务器计算的特点，用户编写独立的代码片段（如函数），在事件触发时执行，而无需关心底层服务器的管理。
D) 向用户提供应用程序开发、部署和管理的环境，用户无需搭建和管理基础设施
- 这种描述更接近于 PaaS（平台即服务），而不是无服务器计算。PaaS 提供开发和部署环境，但通常是针对整个应用，而无服务器计算则是运行独立的代码片段。

因此，正确答案是 C。

# 2.5

67e0a1ee25a08c231173c24af4ff470c

题目中给出的 PUE 值为 1.25。PUE (Power Usage Effectiveness) 的计算公式为：

$\text{PUE} = \frac{\text{数据中心总能耗}}{\text{IT设备能耗}}$

因此，PUE 值越接近 1，表明非 IT 设备的能耗越低。在 PUE=1.25 的情况下，非 IT 设备的能耗占全部能耗的比率可以计算为：

$\frac{1.25 - 1}{1.25} = 0.2$

这意味着非 IT 设备的能耗占比应为 20%。

接下来，分析选项：

A：冷却设备 10%，照明设备 7%，电力设备 3%
总共为 20%，符合要求，因此可能存在。
B：冷却设备 40%，照明设备 30%，电力设备 10%
总共为 80%，远远超过 20%，因此不可能存在。
C：冷却设备 40%，照明设备 25%，电力设备 10%
总共为 75%，也远远超过 20%，因此不可能存在。
D：以上皆不可能
因为 A 是可能的，所以 D 不正确。

因此，正确答案是 A。

# 2.6

C) 为可拓展性

# 二、云计算中的操作系统

# 1. 虚拟化

【云计算复习】第 7 节虚拟化_寄居虚拟化，裸金属虚拟化，全虚拟化，操作系统虚拟化 - CSDN 博客

# 1.1 概念

使用软件对物理计算资源进行抽象，使抽象化后的资源具有与物理计算资源相似的功能 (用软件实现硬件的功能和服务)

包括硬件平台，处理器，存储设备和计算机网络等资源的虚拟化
是云计算提供服务的核心理念

（1）服务器虚拟化在云计算中最重要、最关键。
（2）不论实际上采用了什么样的物理硬件，操作系统都将它们视为一组一致、标准化的硬件。
（3）不同的虚拟机加载的操作系统和应用程序可以是不同的。

虚拟化技术有两个方向：

（1）一个物理的服务器虚拟成若干个独立的逻辑服务器。
（2）若干分散的物理服务器虚拟为一个大的逻辑服务器，比如网格技术。

# 1.2 特点

降低成本、节能
- 一台大主机 Vs. 多台小主机
高灵活性
- 管理多台虚拟机 Vs. 管理多台物理主机
高敏捷性
- 虚拟机迁移 Vs. 物理主机迁移
容错能力强
- 虚拟节点失效 Vs 物理节点失效

# 1.3 分类

硬件虚拟化（服务器虚拟化）
- 全虚拟化（Full virtualization）
- 半虚拟化（Paravirtualization）
- 硬件辅助虚拟化（Hardware-assisted virtualization）
操作系统虚拟化（容器化，containerization）
桌面虚拟化
其他类型虚拟化
- 软件、内存、存储、数据、网络

# 1.3.1 硬件虚拟化和容器化（图片背下来）

# 1.3.2 虚拟机管理程序（Hypervisor）

或称虚拟机监视器（Virtual Machine Monitor，VMM）
是用来创建和运行虚拟机的软件、固件或硬件的统称
- 运行在主机硬件或者主机操作系统之上
- 提供虚拟操作平台，供 Guest OS 运行

两种 Hypervisor

Hosted（寄居）
原生 / 裸金属

寄居虚拟化

（1）寄居虚拟化的虚拟化层一般称为虚拟机监控器（VMM）。
（2）这类虚拟化架构系统损耗比较大。
（3）就操作系统层的虚拟化而言，没有独立的 Hypervisor 层。
（4）结构：

裸机虚拟化

（1）架构中的 VMM 也可以认为是一个操作系统，一般称为 Hypervisor（超级监督者）。
（2）轻量级操作系统。
（3）Hypervisor 实现从虚拟资源到物理资源的映射。
（4）结构：

# 1.4 三种硬件虚拟化技术

（1）起因：当虚拟机中的操作系统通过特权指令访问关键系统资源时，Hypervisor 将接管其请求，并进行相应的模拟处理。
（2）方法：为了使这种机制能够有效地运行，每条特权指令的执行都需要产生 “自陷”（陷入异常），以便 Hypervisor 能够捕获该指令。
（3）作用：Hypervisor 模拟特权指令的执行，并将处理结果返回给指定的客户虚拟系统，实现了不同虚拟机的运行上下文保护与切换，能够虚拟出多个硬件系统，保证了各个客户虚拟系统的有效隔离。

全虚拟化
- VMM 通过二进制翻译（BT）将客户机指令映射到主机指执行
- 客户机并不知道自己被虚拟化
- Guest OS 不需要做任何修改

（1）把一个 OS 所有 CPU、内存、外设等物理设备逻辑抽象变虚拟。
（2）兼容性非常好，不需修改客户机操作系统的源代码；但开销非常大。
（3）软件辅助虚拟化：通过特权解除和陷入模拟。
（4）硬件辅助虚拟化：硬件直接就能区分来自虚拟机和物理机的特权指令。
（5）x86 体系结构的处理器并不是完全支持虚拟化的，因为某些 x86 特权指令在低特权级上下文执行时，不能产生自陷，导致 VMM 无法直接捕获特权指令。
全虚拟化允许在宿主主机上运行多个完全独立的虚拟机，每个虚拟机都具有自己的操作系统和应用程序。
这种方法需要在宿主主机上模拟硬件、操作系统和设备，以使虚拟机能与宿主主机隔离运行
优点和缺点：
全虚拟化技术具有许多优点，如安全性高、可靠性高、易于管理等。
但是，这种技术也需要消耗大量的系统资源，可能会对宿主机的性能产生影响。

半虚拟化
- 客户机通过超级调用（Hypercalls）与虚拟化层交互执行特权和敏感指令，其余指令可以与硬件直接交互
- 客户机知道自己被虚拟化
- Guest OS 需要修改与主机交互的内核代码

（1）只对底层硬件进行部分模拟。
（2）虚拟机在运行时可减少在用户模式和特权模式之间的切换次数，从而降低运行的开销。
（3）优点是性能较优异；缺点在于 GuestOS 的镜像文件并不通用。
（4）修改内核后的 GuestOS 也知道自己就是一台虚拟机，所以能够很好的对核心态指令和敏感指令进行识别和处理。
半虚拟化通过修改操作系统内核，使得虚拟机可以与宿主主机共享硬件资源，提高性能的同时也减少了对硬件的要求
优点和缺点：
半虚拟化技术具有高性能、低资源消耗等优点
但是也需要修改操作系统内核，可能会对系统的稳定性和安全性产生影响

硬件辅助虚拟化
- VMM 集成到硬件中，操作系统特权和敏感指令直接 “陷入” VMM 虚拟化层中
- Guest OS 的内核只需要做少量修改
- 相对全虚拟化提高了运行效率，相对半虚拟化降低了 OS 内核修改的开销

硬件辅助虚拟化：硬件直接就能区分来自虚拟机和物理机的特权指令。
硬件辅助虚拟化是通过硬件来辅助虚拟化的方式。他可以在处理器、内存、网络设备和存储设备等多个方面提供帮助，提高虚拟机的性能和效率。

# 1.5 容器化

操作系统层的虚拟化，多个隔离的实例（容器）共享操作系统内核
- 不必运行完整的 OS
- 只分配程序运行必需的资源
本质上是主机的一个进程
- 通过 namespace 实现资源隔离
- 通过 cgroups 实现资源限制
- 通过写时复制（COW）技术实现高效文件操作

# 1.6 实际

# 2. 多租户

# 2.1 概念

一种软件架构，使得同一个硬件、系统或者应用程序可以同时服务多个独立的租户（一个租户通常包括一群权限共享的用户），不同租户享有专用的数据、配置和功能等等（隔离性）

多用户环境下使用同一套服务
用户间的数据和环境实现隔离
实现定制化配置和功能

多租户技术带来的优势

降低了云系统的成本，提高了云服务的实用性
节约成本
- 资源池化的一种体现
快速启动
- 不用为每个租户单独启动一个应用
高可扩展性
- 有限的资源支持更多的租户
易维护性
- 一次维护、更新或升级服务所有租户

# 2.2 实现方式

资源层
- 计算资源的隔离（虚拟机、虚拟网络）
应用层，隔离不同租户的应用程序环境
- 通过同一应用的不同实例实现隔离
数据层，隔离不同租户的数据
- 数据库隔离
- 共享数据库，存储区隔离
- 共享数据库，结构描述隔离
- 共享数据库，共享结构描述，表格隔离

# 2.3 Hadoop 实例

Hadoop 中的 YARN 是什么？请解释其作用和架构。_hadoop yarn 的作用是什么 - CSDN 博客

Yarn: YARN 是 Hadoop 的一个重要组件，它是一个资源管理器和作业调度器，用于管理和调度集群中的计算资源。YARN 的主要目标是提供一个通用的资源管理框架，使得 Hadoop 能够更好地支持各种计算模型和应用程序。

# 2.5 其他实例

# 2.6 其他虚拟化

存储设备虚拟化

1. 是指将存储网络中的各个分散且异构的存储设备按照一定的策略映射成一个统一的连续编址的逻辑存储空间，称为虚拟存储池。
2. 存储虚拟化的实现方式
（1）基于主机的存储虚拟化。
（2）基于存储设备的存储虚拟化。
（3）基于网络的存储虚拟化。

网络虚拟化

1. 分三类
（1）核心层网络虚拟化：核心网络设备的虚拟化。
（2）接入层网络虚拟化：实现数据中心接入层的分级设计。
（3）虚拟机网络虚拟化：包括物理网卡虚拟化和虚拟网络交换机。
2. 桌面虚拟化提一嘴，就是类似手机双开页面。

# 3. 分布式系统

# 3.1 概念

不同计算机利用网络互联，通过消息传递沟通并协同完成任务的系统
- 电信网络
- 基于网络的应用
- 实时处理系统
- 各种并行计算系统

云是一个分布式系统

# 3.2 特点与云计算

容错性：单一的故障不会影响整个系统的正常运行，比如冗余、故障恢复
- 高可靠和高可用
高可扩展性：自由对节点或功能进行扩充
- 弹性伸缩
并发：多台机器同时访问同一数据
- 数据的一致性和安全性
透明性：用户无需了解对分布式系统的内部结构
- XaaS

# 3.3 分布式应用

# 3.3.1 分布式计算

研究如何利用分布式系统进行高效计算

MapReduce：基于数据流的大规模数据处理编程模型
MPI (Message Passing Interface)：基于消息传递的模型
BSP (Bulk Synchronous Parallel)：分布式图计算模型
实时流处理系统模型

# 3.3.2 分布式存储

通过网络接连将数据存储在多个计算机节点上，通常用一种复制（多副本）的方式

结构化存储（分布式数据库）：MySQL / PostgreSQL (GreenPlum)
非结构化存储：HDFS (Hadoop File System) / GFS (Google File System)
半结构化存储：Bigtable / Dynamo / Hbase
内存存储：Redis / MonetDB
NewSQL：Google Spanner

# 3.3.3 分布式资源管理

管理和分配分布式系统的资源

集群管理：Mesos / Omega / Borg / Yarn
容器管理：Docker Swarn / Kubernetes

# 3.4 MapReduce

起源

将分布式计算抽象化，隐藏上述实现细节

Map function：将原始数据转化为 key/value pair
Reduce function：根据 key 聚合 value，得到最后的计算结果

数据流

Input reader
- 读入文件并划分成固定大小的存储块（split，通常 64M 或 128M），并分配到 maper 节点
Map 函数 (分割完后 Map)
- 将 split 中的数据根据问题的需求转换为 key/value pair 并输出
Partition 函数
- 将 map 函数的输出结果，根据 key 值分配到不同的 reducer 节点
Comparison 函数
- 对分配到每个 reducer 节点 key/value pair 进行排序
Reduce 函数 (倒数第二个)
- 根据问题需求对每个 key 的 value 进行迭代计算，输出 key 对应的最终结果
Output writer
- 将 reducer 的输出结果写入磁盘文件系统

应用

# 3.5 YARN & Hadoop

# 3.5.1 出现契机

一开始为解决 Hadoop1.X 的单点瓶颈问题，后逐渐成为 Hadoop 上的通用资源管理系统，为 Hadoop 生态中的应用提供统一资源管理

YARN 出现以前的 Hadoop

单节点的 JobTracker (JT) 同时负责资源管理和作业控制
TaskTracker 负责向 JobTracker 汇报资源使用和作业执行情况
JT 不易 Scale-out
JT 只能执行 MapReduce 框架 +

# 3.5.2 设计理念

减轻 JobTracker 的工作负载，将资源管理和作业控制拆分为两个进程
- 资源管理进程与具体作业无关，只负责全局资源分配（ResourceManager）
- 作业控制进程由应用程序模块管理，每个应用程序模块负责一个作业进程（ApplicationMaster）
资源管理功能与应用程序功能剥离，使得 Hadoop 可以支持多种计算框架
- 具体的计算框架由 ApplicationMaster 来实现和管理

# 3.5.3 总体架构

ResourceManager (RM) 只负责整个集群的资源管理和调度
NodeManager (NM) 管理自身节点的资源。向 RM 汇报自身节点资源使用情况，接受 RM 的资源调度；处理来自 AM 的作业执行命令
ApplicationMaster (AM) 负责管理应用程序（作业）。向 RM 申请资源，分配给内部作业使用；向 NM 发出作业启动或者停止请求

# 3.5.4 控制流程

# 3.5.5 意义

解决了 Hadoop 1.X 的单点瓶颈问题
- 将 JobTracker 分解成 ResourceManager 和 ApplicationMaster
可以在 Hadoop 集群上同时管理多种计算框架
针对不同的计算框架实现对应的 ApplicationMaster
由 ApplicationMaster 去完成具体的作业管理和资源调配
MapReduce，Spark，Flink 等可以在一个 Hadoop 集群上同时运行

# 4. 总结

云计算的三大核心理念
- 数据中心
- 虚拟化
- 多租户
云本质上是一个分布式系统
- 分布式计算
- 分布式存储
- 分布式资源管理

# 三、云计算网络

计算机网络（ComputerNetworks）是云计算平台的重要基础设施

云通过宽带网络向终端提供服务（NIST 定义的云计算五大特征之一：Broad network access，广泛的宽带访问）
云本质上是一个分布式系统，云中的各个组件通过网络互相通信
通过私有网络隔离实现云服务的多租户特性

# 1. 计算机网络基础

# 1.1 网络节点

网络终端 (Network Endpoint): 位于网络边缘的通信设备、
集线器 (Hub): 连接多个终端组成计算机网络，以广播的方式传输数据
交换机 (Switch): 连接多个终端组成计算机网络，可以向特定终端传输数据 (也可以广播)
路由器 (Router): 连接多个计算机网络，负责在不同网络间传输数据

# 1.1.1 集线器

一般工作于 OSI 架构的物理层（Physical layer）
- 维护 hub table，记录哪些端口（port）连接了终端设备
数据以广播形式传输到所有已连接的终端设备
- 数据传输具有安全隐患
- 容易造成网络堵塞（广播风暴），降低网络传输效率

# 1.1.2 交换机（Switch）

一般工作于 OSI 架构的数据链路层（Data link layer）
- 维护 switch table，识别并记录终端的 MAC 地址
数据根据 MAC 地址被传输到指定的终端设备
- 有效减少不必要的网络流量
- 可以以全双工模式工作，提高数据传输效率

# 1.1.3 路由器（Router）

一般工作于 OSI 架构的网络层（Network layer）
- 维护 Routing table，识别并记录附近连接网络的 IP 地址
负责和其他网络交换数据
- 根据 IP 地址传输数据
- 起到网关（gateway）的作用：传输目的地（IP）是自身所连接的网络，则接收数据；否则转发数据。

# 1.2 网络链路

连接相邻网络节点的物理设备
- 双绞线：由两根采用一定规则并排绞合、相互绝缘的铜导线组成，一般用于局域网（LAN）和广域网（WAN），e.g., 家用网线
- 同轴电缆：由导体铜质芯线、绝缘层、网络编织屏蔽层和塑料外层构成，传输速率和距离高于双绞线，一般用于远距离传输
- 光纤：利用光导纤维传递光脉冲来进行通讯，传输效率和距离远高于同轴电缆，但价格昂贵，一般用于远距离传输
- 无线传输介质：利用无线电波、微波、红外线、激光和卫星进行通信，广泛应用于无线局域网（WLAN）

# 1.3 网络类型

网络节点 + 网络链路就构成了计算机网络
集线器和交换机用于创建计算机网络
- LAN，WAN
路由器用于连接计算机网络
Internet

# 1.4 子网

# 1.4.1 概念

是一个 IP 网络的逻辑分区，构建这样逻辑分区的过程叫做子网划分（Subnetting）
- 同一子网内的计算机可以直接互通
- 划分子网可以减轻网络阻塞、提高传输效率和保障网络安全
一个子网由 Network ID 来标识和划分
- Network ID 由网络前缀和掩码组成，比如 192.168.1.0/24
- 掩码决定了一个子网的网络地址和主机地址（同时也决定了子网中的最大主机数量）

# 1.4.2 子网掩码

二进制 / 十进制法：
- 比如 255.255.255.0
- 11111111.11111111.11111111.00000000
“/” 加上数字 1~32：比如 /24

# 1.4.3 子网划分

IP 地址计算 --- 子网掩码确定和子网划分等详解 (附常见相关习题)_子网掩码计算例题和讲解 - CSDN 博客

简单搞懂子网划分，学会子网划分这篇就够了（例题详解）_子网划分例题 - CSDN 博客

根据 Network ID 计算子网大小和主机地址

将网络 192.168.4.0/24 划分为 4 个子网

# 1.5 网络体系结构

# 1.5.1 计算机网络组件

# 1.5.2 计算机网络体系结构

计算机网络的两种经典体系架构
- OSI architecture (Open Systems Interconnection，7 层协议架构)
- Internet architecture (TCP/IP 协议架构)

每一层定义的是对应组件中的协议（Protocol），而非软硬件本身！

# 1.5.3 对应关系

# 1.5.4 OSI 7 层协议架构

# 1.5.4.1 应用层

应用层（Application Layer）：定义了网络应用 / 软件传输数据的协议

# 1.5.4.2 表示层

表示层（Presentation Layer）：与应用层通信，对数据进行格式转换、压缩 / 解压缩、加密 / 解密

# 1.5.4.3 会话层

会话层（Session Layer）：建立和管理应用之间的通信，同时负责身份验证和授权管理

# 1.5.4.4 传输层

传输层（Transport Layer）：建立和管理终端之间的连接和数据传输，负责数据分段、流量控制和错误管理

# 1.5.4.5 网络层

网络层（Network Layer）：识别 IP 地址并加入到数据分段组成数据包（packet），建立传输路线，寻找最佳路径

# 1.5.4.6 数据链路层

数据链路层（Data Link Layer）：给数据包添加 MAC 地址和结尾信息，打包成完整的数据帧，负责与物理层的数据传输以及错误检测

# 1.5.4.7 物理层

物理层（Physical Layer）：将数据帧转化为电平信号在物理介质上传输

# 1.5.4.8 实例

# 2. 计算机网络的虚拟化

# 2.1 各虚拟化对应 OSI 层级

# 2.2 L1/L2 虚拟化

即 OSI 第一层和第二层的虚拟化

网络适配器的虚拟化（Network Adapter/NIC，通常是以太网卡或无线网卡）

每个联网的物理主机都有至少一个网络适配器
对应的，每个联网的 VM 都需要一个虚拟 NIC，或 VNIC
三种实现方法
- 在 Hypervisor 中实现 VNIC 和 VSwitch（virtual Ethernet bridge，VEB）
- 在 NIC 中实现 VNIC 和 Vswitch
- 在 Switch 中直接实现 VM 之间交互（virtual Ethernet port aggregator，VEPA）

三种实现方法

# 2.3 L2 虚拟化

交换机的虚拟化
- Virtual Switch（通常和 VNIC 一起在 VM 中使用）
- Virtual Bridge
Virtual Bridge
- 通常一个交换机只有 32～128 个端口，在一个实际的 L2 网络中往往不够
- 通过交换机的可扩展端口，将多个交换机在链路层桥接，形成一个包含大量端口的虚拟桥

# 2.4 L3 虚拟化

虚拟化的 L3 网络，实现租户网络隔离和动态分配
- 覆盖网络（Overlay Network）
- 虚拟私有云（Virtual Private Cloud）
一台物理主机中的 VM 往往属于不同的租户
- 需要将不同租户的网络进行隔离
同一个租户的 VM 也往往存在于多台物理主机中
- 需要将同一租户的 VM 动态联网（L3 层）

# 3. 云计算中的虚拟化网络

# 3.1 覆盖网络

# 3.1.1 概念

特别注明，底层网络相比覆盖网络不一定在 OSI 模型更底层，如 VXLAN 底层网络为 L3 层，覆盖网络为 L2 层

# 3.1.2 封装

将覆盖网络 packet 封装在底层网络 packet 中进行传输（encapsulation）
当数据到达目的地后再将 packet 解封（decapsulation）
类似 L3 $\rightarrow$ L2 层数据封装
是实现覆盖网络的关键技术

# 3.1.3 封装与隧道

隧道协议（Tunneling Protocol）
- 使用一种网络协议，将另一个网络协议封装在负载部分
- 使得数据可以在不兼容的网络上传输，或在不安全的网络上提供一个安全路径（例：VPN）
- 常见隧道协议如 IPSec，GRE，SSH，SOCKS
- 隧道协议往往伴随数据加密技术（encryption）
覆盖网络本质上是使用封装技术，在原有网络的基础上构建的隧道网络

# 3.1.4 VLAN

对 L2 层网络（LAN）进行逻辑划分和隔离形成的虚拟局域网
- 使用具有 VLAN 功能的（VLAN-enabled）交换机连接主机
- 在数据包中加入 VLAN tag 进行逻辑隔离，即该数据包属于 tag 所标识的 VLAN
- IEEE802.1Q 规范中，VLAN tag 有 12bits 用来表示 VLAN ID，一个使用该规范的局域网最多能构建 2^12=4096 个 VLANs
- 可扩展性成为在云计算中的瓶颈

# 3.1.5 云计算中的常见覆盖网络技术

NVGRE（Network Virtualization using Generic Routing Encapsulation）
VXLAN（Virtual Extensive Local Area Network）
相同点
- 两者都使用封装和隧道创建 VLANs
- 两者都用 L3 协议封装 L2 协议，在 L3 网络上构建 L2 隧道
不同点
- 主要支持厂商不同：NVGER 由 Microsoft 支持，VXLAN 由 Cisco 支持
- 使用的隧道协议不同：NVGER 使用 GER 协议，VXLAN 使用 UDP 协议
- 负载均衡方式不同：NVGRE 主机使用多个 IP 地址，VXLAN 使用端口 Hash

# 3.1.6 云计算中的物理网络

缺陷

# 3.1.7 构建覆盖网络

# 3.1.7.1 使用 VXLAN 协议构建覆盖网络

虚拟隧道端点（Virtual Tunnel End Point，VTEP）
- 一种虚拟交换机，学习并维护 VM 的 MAC 地址到另一个 VM 的 VTEP 的 IP 地址的映射
- 映射关系可以人工维护或动态学习
- 负责对原始 packet 进行封装和解封

正确答案是 B 。
以下是对各选项的分析：
A 选项：错误。VXLAN 的下层网络（Underlay Network）通常工作在第三层（L3），即 IP 层，而不是七层协议的 L1 层。
B 选项：正确。VXLAN 的覆盖网络（Overlay Network）工作在二层（L2），提供二层网络隔离，模拟虚拟化的广播域。
C 选项：错误。VXLAN 的虚拟隧道端点（VTEP）维护 VM 的 MAC 地址到另一个 VM 的 VTEP 的 IP 地址的映射射，用于在虚拟机之间建立通信。
D 选项：错误。VXLAN 并不是通过动态分配 UDP 端口来实现租户之间的隔离，而是通过 24 位的 VXLAN 网络标识符（VNI）来区分不同租户的网络。

# 3.1.7.2 VXLAN 封装

背下来 Packet 结构

收发 SERVER 的 UDP 端口号中，SRC 端口号往往通过 Hash 动态分配，实现负载均衡（DST 是指定的）

# 3.1.7.3 VXLAN 封装

# 3.1.7.4 多租户隔离

从用户视角看，数据从 10.0.0.1 发送到 10.0.0.2

从 VTEP 来看，数据从 192.168.1.10 发送到 192.168.2.20

# 3.1.8 使用 Open vSwitch 和 VXLAN 实现覆盖网络

OpenStack 云平台中大量使用 Open vSwitch 和 VXLAN 实现覆盖网络
Open vSwitch 是一个 Linux 基金会项目，用以实现运行在 Linux 系统上的分布式虚拟 Switch
- 利用 Open vSwitch 可以创建多个虚拟交换机、虚拟局域网 VLAN，并将 VM 进行互联

# 4. 软件定义网络

# 4.1 概念

SDN：用集中化的智能网络管理进行联网，从而实现动态和高效可编程的网络配置，以改善网络性能，比传统网络管理更适合在云计算中使用
网络传输不再只依赖静态网络架构，而是可以通过接口进行集中和动态管理
重要特征：
- 1）分离计算机网络中的控制平面和数据平面的功能；
- 2）构建全局的控制平面智能（中央控制器），实现整体路由决策
于 2011 年前后随着 OpenFlow 协议被提出和推广

# 4.1.1 控制平面（Control plane）

路由器中负责构建网络拓扑和决定数据路由的体系结构
- 路由决策
- 交换路由表信息
- 处理控制平面数据包，更新路由表
简言之，决定如何传输数据（偏软件部分）

# 4.1.2 数据平面（Data plane）

又称转发平面（Forwarding 、plane），路由器中决定如何处理数据包的体系结构
- 查看数据包的目的地址
- 根据控制平面的制定的规则转发数据
简言之，负责将数据传输至目的地（偏硬件部分）

# 4.1.3 传统路由方式的缺陷

传统设备中控制平面和数据平面统一管理，软硬件规范由通信厂商（比如 Cisco / 华为）垄断，用户对路由协议没有主导权
- 新的网络协议无法在旧设备上使用
- 网络行为无法动态改变
- Vendor lock-in 供应商锁定
SDN 通过将控制平面和数据平面分离，实现了网络传输中软件和硬件的解耦合
- 路由行为由中央控制器（软件）动态管理
- 硬件设备根据中央控制器的决策传输数据

# 4.2 SDN 的系统架构

应用层
- 各种基于网络的应用
控制器层
- 控制平面所在的层
- 核心为 SDN 中央控制器
基础设施层
- 构成底层网络的网络设备

# 4.3 SDN 的三种实现方式

Open SDN
- 基于 OpenFlow 的 SDN 架构
SDN by APIs
- 在原有网络设备上增加 API 层
SDN by Overlays
- 利用覆盖网络构建 SDN

# 4.3.1 Open SDN

基于 OpenFlow 制定的 SDN 规范
SDN 中央控制器直接和网络设备（Router/Switch）的数据平面交换信息，控制数据平面的传输行为
一般来讲需要升级硬件设备来支持 OpenFlow 的协议

# 4.3.2 SDN by APIs

在传统网络设备中添加一层 API 层（RESTful API）
使传统网络设备可以使用 OpenFlow 以外的标准被 SDN controller 控制
例如 OpenDaylight

# 4.3.3 SDN by Overlays

在 Hypervisor 中实现 SDN controller 功能，不用对现有网络设备做任何升级
在 L3 网络上构建 L2 覆盖网络，Hypervisor 中的 SDN ontroller 动态学习路由规则
例如 Juniper Networks

# 4.3.4 对比

Open SDN 中 SDN controller 直接和网络设备通信
- 效率最高，但是需要升级网络设备以支持 OpenFlow 规范
- SDN controller（中央控制器）有单点失败风险
API SDN 针对传统网络设备添加 RESTful API 层
- 从传统设备到支持 OpenFlow 规范设备的过渡方法
- 但是缺乏对网络流状态的感知和对数据包的检测
Overlay SDN 通过构建覆盖网络实现 SDN
- 不需要对网络设备进行更换，甚至不需要改变虚拟设备
- 效率较低，并且需要一些手动配置来维护网络

# 4.4 VPC - 云计算中的 SDN：Virtual Private Cloud

虚拟私有云
- 属于租户的、逻辑隔离的网络环境
- 租户对属于自己的 VPC 中的云资源有完全自主管理权
VPC 中的网络功能
- 子网：用户可以根据需要将 VPC 划分成多个子网
- NAT 网关：VPC 中资源访问外网的统一出口
- 网络 ACL：控制进出子网流量的规则

# 4.4.1 VPC 是一个虚拟私有数据中心

VPC 在云中被分配一个网段（VPC 本身可以视为一个子网）
- 通过 API 管理网络（SDN）
- Built-in DHCP 和 DNS
- Built-in Firewall
在 VPC 中可以运行各种云资源
用户通过连接 VPC 访问其中的云资源
- Built-in routing tables

# 4.4.2 VPC 中的覆盖网络

VPC 内部的资源通过覆盖网络互相连接 (重要)

使用 VPC Encapsulation 在底层物理网络上构建覆盖网络

使用 Mapping service 构建路由规则（类似 VXLAN 中的 VTEP 的功能）

# 4.4.3 VPC 中的资源与外网通信

弹性 IP
- 公网 IP
- 每个资源可以分配一个弹性 IP，与外网直接通信
NAT 网关
- 由于安全、经济等原因，很多资源不会分配弹性 IP
- 通过 NAT 网关（VPC 的统一外网出口）与外网通信

# 4.4.4 VPC 的负载均衡

可以视为 NAT 网关的反向流量控制
- NAT 网关将 VPC 中资源的流量会聚，传到外网（通常用 Hashing 算法）
- 负载均衡器（load balancer）接受外网流量，均衡分配到 VPC 中的资源（通常用 Sharding 算法）

# 4.4.5 Ucloud 中的 VPC

ACL 最全详解：原理及作用、分类及特点、配置及需求 - CSDN 博客

acl: 安全组配置

# 5. 数据中心网络拓扑结构

数据中心网络是连接数据中心各种资源的关键基础设施
- Data Center Network，DCN
- DCN 必须高可扩展，并且高效连接海量的计算资源
常见的 DCN 拓扑结构
- 三层架构（Three tier）
- 胖树（Fat tree）
- Dcell
- BCube

# 5.1 Three Tier 架构

从下往上依次为
- Access Layer（接入层）：
  - 也称为 TOR 层（Top-Of-Rack）。
  - 负责将服务器或终端设备连接到网络上。
- Aggregation Layer（汇聚层）：
  - 聚合来自多个接入层交换机的流量并将其传送到核心层。
  - 在大型网络中负责流量的汇聚和转发。
- Core Layer（核心层）：
  - 主要负责高速、可靠的网络核心转发。
  - 连接多个汇聚层，构成网络的核心传输部分。
在云计算中的缺点
- Aggregation 层容易成为传输瓶颈
- 带宽利用率低

# 5.2 Fat Tree 架构

Fat-Tree Topo Architecture（胖树拓扑结构）_胖树结构 - CSDN 博客

每台交换机都有 k 个端口；
核心层为顶层，一共有 (k/2)^2 个交换机； $k * k/4,每台核心交换机连接k个PoD,每个PoD里汇聚层的一半端口用来连接core交换机，另一半用来连接接入层$
一共有 k 个 pod，每个 pod 有 k 台交换机组成。其中汇聚层和接入层各占 k/2 台交换机；
接入层每个交换机可以容纳 k/2 台服务器（因为一半端口连接汇聚层，另一半连接服务器)，因此，k 元 Fat-Tree 一共有 k 个 pod，每个 pod 容纳 $k/2 * k/2$ 个服务器，所有 pod 共能容纳 $k*k*k/4$ 台服务器；
任意两个 pod 之间存在 k 条路径
共需要 $k*k+k*k/4$ 台交换机

在 Fat-Tree 拓扑结构中，k 个端口的概念主要体现在每台交换机的设计中。这些端口数决定了整个网络结构的规模和连接方式。具体来说，k 个端口体现在以下几个方面：
核心层交换机：
核心层共有 ((k/2)^2) 台交换机。
核心层交换机使用这些端口连接到不同的 Pod 中的汇聚层交换机，每台核心层交换机连接到每个 Pod 的所有汇聚层交换机。
Pod 结构：
一个 Fat-Tree 结构包含 k 个 Pod，每个 Pod 内部由 k 台交换机组成。
每个 Pod 中的交换机分为汇聚层和接入层，每层各有 (k/2) 台交换机。
这种划分方式保证了每个交换机都具有 k 个端口，其中：
汇聚层交换机的 k/2 个端口连接到核心层交换机，另外 k/2 个端口连接到同一 Pod 中的接入层交换机。
接入层交换机的 k/2 个端口连接到汇聚层交换机，另外 k/2 个端口用于连接到服务器。
服务器连接：
在每个 Pod 的接入层中，每台接入层交换机可以连接到 k/2 台服务器，这也是因为每台交换机拥有 k 个端口。
因此，一个 k 元 Fat-Tree 拓扑的一个 Pod 中可以容纳 (k \times k/4) 台服务器，而整个网络可以容纳 (k \times k \times k / 4) 台服务器。
# 端口的分配
总结来说，k 个端口的设计体现在每台交换机的端口分配上：
核心层交换机的端口用于连接不同 Pod 中的汇聚层交换机。
汇聚层交换机的端口分配一半用于连接核心层，另一半用于连接同一 Pod 的接入层。
接入层交换机的端口分配一半用于连接汇聚层，另一半用于连接服务器。
这种设计保证了在网络拓扑中带宽和路径数的扩展性，同时降低了复杂性和成本。

# 5.3 其他常见拓扑结构

# 6. 总结

# 7. 习题

# 7.1

D 选项：数据平面决定如何传输数据，这一描述有误，因为数据平面并不负责决定传输策略，它仅负责执行控制平面下发的转发决策。

控制平面
路由器中负责构建网络拓扑和决定数据路由的体系结构
路由决策
交换路由表信息
处理控制平面数据包，更新路由表
简言之，决定如何传输数据（偏软件部分）
数据平面
又称转发平面（Forwarding 、plane），路由器中决定如何处理数据包的体系结构
查看数据包的目的地址
根据控制平面的制定的规则转发数据
简言之，负责将数据传输至目的地（偏硬件部分）

# 7.2

C) VPC 内部的资源通过覆盖网络互相连接 (重要)

使用 VPC Encapsulation 在底层物理网络上构建覆盖网络

# 7.3

$k*k*k/4=8*8*8/4=128$

# 四、云数据管理

# 1. 谷歌文件系统

三分钟带你弄懂 GFS（Google File System）_白话 gfs-CSDN 博客

GFS 分布式文件系统（理论 + 实操）_glfs-CSDN 博客

演变
GFS 整体架构
GFS 的存储设计
GFS 的 master 设计
GFS 的高可用设计
GFS 的读写流程
GFS 的一致性模型
总结

# 1.0 演变

# 1.1 整体架构

1）选择仅使用一个主服务器（单主模式）

2）选择仅将一些元数据存储在非易失性存储中

3）选择弱一致性保证

在这里插入图片描述

# 1.2 存储设计

A1. 文件怎样分散存储在多台服务器上？
B1. 怎样支持 ** 大文件（几个 GB）** 存储？
考虑到文件可能非常大，并且大小不均。GFS 没有选择直接以文件为单位进行存储，而是把文件分为一个个 chunk 来存储。GFS 把每个 chunk 设为 64MB。
这个思路在分布式领域非常常见。几乎所有涉及存储的系统，都会把文件或数据分割为相同大小的块进行存储。当然，不同类型的应用，块的大小也不相同。
相对而言，64MB 这个值是偏大的。为什么 GFS 会这么设计呢？
- ① 使用 GFS 的系统需要存储的文件都偏大（几 GB），所以较大的 chunk 可以有效减少系统内部的寻址和交互次数；
- ② 大的 chunk 意味着 client 可能在一个 chunk 上执行多次操作，这可以复用 TCP 连接，节省网络开销；
- ③更大的 chunk 可以减少 chunk 数量，从而节省元数据存储开销，相当于节省了系统内最
  珍贵的内存资源，这对 GFS 来讲是非常关键的。
当然，更大的 chunk 意味着多个线程同时操作一个 chunk 的可能性增加，容易产生热点问题，对这个问题，GFS 在一致性设计方面做出了对于性能的妥协
A1. 文件怎样分散存储在多台服务器上？ —— 分割存储
B1. 怎样支持 ** 大文件（几个 GB）** 存储？—— 采用了更大的 chunk，以及配套的一致性策略

# 1.3 master 设计

A1. 怎样实现自动扩缩容？
A2. 怎样知道一个文件存储在哪台机器上？
文件位置等信息→元数据
管理元数据节点设计为一个单点还是设计成 ** 多节点（分布式）** 呢？

Google 最终选择了单 master 节点的方案。
GFS 设计了单个 master 节点，用来存储整个文件系统的三类元数据：
- 所有文件和 chunk 的 namespace【持久化】
- 文件到 chunk 的映射【持久化】
- 每个 chunk 的位置【不持久化】
由此，我们就可以简单推断出 GFS 读取一个文件的过程了：
- 文件名→获取文件对应的所有 chunk 名→获取所有 chunk 的位置→依次到对应的 chunkserver 中读取 chunk
- 这个是基本的逻辑，但 GFS 实际的读取过程是经过了很多优化的，这个我们之后会谈到。

为什么 chunk 的位置不做持久化呢？
- 因为 master 在重启的时候，可以从各个 chunkserver 处收集 chunk 的位置信息。

GFS 采用了一系列措施来确保 master 不会成为整个系统的瓶颈：
- ①GFS 所有的数据流都不经过 master，而是直接由 client 和 chunkserver 交互；
  - GFS 把控制流和数据流分离，只有控制流才会经过 master。
- ②GFS 的 client 会缓存 master 中的元数据，在大部分情况下，都无需访问 master；
- ③为了避免 master 的内存成为系统的瓶颈，GFS 采用了一些手段来节省 master 的内存，包括增大 chunk 的大小以节省 chunk 的数量、对元数据进行定制化的压缩等。
通过这些手段，GFS 不仅实现了由一个单点的 master 提供整个系统所有的元数据服务，还可以把所有的元数据都放在 master 的内存中，从而让元数据服务特别的高效。
一个 64MB 的 chunk，它的元数据小于 64B（64 字节）
假设一个文件存储三份，每份的元数据都是独立的。那么 1TB 数据对应的元数据大小为
- 即使存储 1PB 的数据也只有 3GB 的元数据，2 块 3GB 大小的内存，在价格上是完全可以接受的。
A1. 怎样实现自动扩缩容？ —— 在 master 单点上增减、调整 chunk 的元数据即可
A2. 怎样知道一个文件存储在哪台机器上？—— 根据 master 中文件到 chunk 再到 chunk 位置的映射来定位具体的 chunkserver
时至今日，大部分分布式系统还是会倾向于选择中心节点。因为单点瓶颈并不像想的那么难解决，非中心节点的实现难度也不如想象中那样可控。

# 1.4 高可用设计

A3. 怎样保证服务器在故障时文件不损坏不丢失？
B2. 超多机器的情况下，怎样实现自动监控、容错与恢复？
高可用问题现在比较通用的做法是共识算法，比如 Paxos 和 Raft。
但 GFS 诞生的时候，共识算法不像现在这么成熟，所以 GFS 借鉴了主备的思想，为系统的元数据和文件数据都单独设计了高可用方案。
因为 Google 的文件量很大，所以 GFS 的机器总数可能非常的多，从而个别机器宕机的发生会十分频繁。所以面对节点宕机之类的小问题，GFS 应能自动解决，即自动切换主备 (B2 问题)。
数据 / 服务的高可用（逻辑概念）和 物理节点的宕机（物理概念）的联系和区别。
我们下面分别讨论 GFS 的元数据和文件数据的高可用。

# 1.4.1 master 的高可用设计

master 的三类元数据中，namespace 和文件与 chunk 的对应关系，因为只在 master 中存在，是必须要持久化的，也自然是要保证其高可用的。
GFS 在正在使用的 master 称为 primary master。在 primary master 之外，GFS 还维持一个 shadow master 作为备份。

Master 在正常运行时，对元数据做的所有修改操作，都要先记录日志（WAL），再真正去修改内存中的元数据。
primary master 会实时向 shadow master 同步 WAL，只有 shadow master 同步日志完成，元数据修改操作才算成功。

流程

生成新增元数据的日志并写入本地磁盘 →
把 WAL 传输给 shadow master →
得到反馈后再正式修改 primary master 的内存。
如何实现自动切换？
如果 master 宕机，会通过 Google 的 Chubby (本质上是共识算法) 来识别并切换到 shadowmaster，这个切换是秒级的。
master 的高可用机制就和 MySQL 的主备机制非常像。

# 1.4.2 chunk 的高可用设计

文件是被拆为一个个 chunk 来进行存储的，每个 chunk 都有三个副本。所以，文件数据的高可用是以 chunk 为维度来保持的。
没法在 chunkserver 之间建立物理上的主备关系，那怎么把一个 chunk 的不同副本之间联系起来呢？
GFS 的唯一中心节点 ——master 就可以发挥作用，维持 chunk 的副本信息。

GFS 保证 chunk 高可用性的思路：
在 GFS 中，对一个 chunk 的每次写入，必须确保在三个副本中的写入都完成，才视为写入完成 →
一个 chunk 的所有副本都会具有完整的数据 →
如果一个 chunkserver 宕机，它上面的所有 chunk 都有另外两个副本依旧可以保存这个 chunk 的数据 →
如果这个宕机的副本在一段时间之后还没有恢复，那么 master 就可以在另一个 chunkserver 重建一个副本，从而始终把 chunk 的副本数目维持在 3 个（可以设置）。
GFS 维持每个 chunk 的校验和，读取时可以通过校验和进行数据的校验。如果校验和不匹配，chunkserver 会反馈给 master 处理，master 会选择其他副本进行读取，并重建此 chunk 副本。
为了减少对 master 的压力，GFS 采用了一种 ** 租约（Lease）** 机制，把文件的读写权限下放给某一个 chunk 副本。
- Master 可以把租约授权给某个 chunk 副本，我们把这个 chunk 副本称为 primary，在租约生效的一段时间内，对这个 chunk 的写操作直接由这个副本负责，租约的有效期一般为 60 秒。
租约的主备只决定控制流走向，不影响数据流。
Chunk 副本的放置也是一个关键问题，GFS 中有三种情况需要 master 发起创建 chunk 副本，分别是新 chunk 创建、chunk 副本复制（re-replication）和负载均衡（rebalancing）。
副本复制则是指因为某些原因，比如一个副本所在的 chunkserver 宕机，导致 chunk 副本数小于预期值（一般为 3）后，新增一个 chunk 副本；
负载均衡则发生在 master 定期对 chunkserver 的监测，如果发现某个 chunkserver 的负载过高，就会执行负载均衡操作，把 chunk 副本搬到另外的 chunkserver 上。当然，这里的 “搬迁” 操作，实际上就是新建 chunk 和删除原 chunk 的操作。
这三个操作中，master 对副本位置的选择策略是相同的，要遵循以下三点：
- ①新副本所在的 chunkserver 的资源利用率较低；
- ②新副本所在的 chunkserver 最近创建的 chunk 副本不多。这里是为了防止某个 chunkserver 瞬间增加大量副本，成为热点；
- ③chunk 的其他副本不能在同一机架。这里是为了保证机架或机房级别的高可用。

# 1.4.3 总结

• A3. 怎样保证服务器在故障时文件不损坏不丢失？——master 的 WAL 和主备、chunk 的多副本

• B2. 超多机器的情况下，怎样实现自动监控、容错与恢复？——master 的主备切换由 chubby 负责，chunk 的租约、副本位置与数量由 master 负责

# 1.5 读写流程

A4. 使用多副本的话，怎样保证副本之间的一致？
B3. 怎样支持快速的顺序读和追加写？
文件系统的读写流程 ↔ 一致性机制
读与写是文件系统最主要的对外接口，也是其性能最核心的体现。
GFS 作为一个文件系统，对读写的需求是什么样的呢？
- 读取 → 快速，为了极致的性能，可以读到落后的版本，但一定不能是错误的
- 写入 → 进一步分为两种：改写（overwrite）和追加（append）
- 改写 → 正确，通常不用在意性能。在意性能的改写可以转为追加。
- 追加 → 快速，为了极致的性能，可以允许一定的异常，但追加的数据一定不能丢失。

# 1.5.1 写入流程

写入时要在三个副本都完成写入后才能返回写入结果。
GFS 的写入采用了两个在现在看来都非常高端的技术：
- ①流水线技术
- ②数据流与控制流分离技术
其中流水线技术，像右图这样，client 会把文件数据发往离自己最近的一个副本，无论它是否是主（是否持有租约）。这个副本在接收到数据后，就立刻向其他副本转发（一边接收，一边转发）。这样就控制了数据的流向，节省了网络传输代价。
与流水线技术对应的是普通的主备同步，数据是从 Client 到主，再从主到备这样单向流动。
比如 S1 S2 S3 三个 chunkserver，Client 在北京，S1 是主，在上海；S2 S3 是备，在北京。
- 主备同步：Client → S1 → S2，S1 → S3，两次跨地域传输
- 流水线同步：Client → S2/S3 → S1，一次跨地域传输
而数据流和控制流分离，意味着 GFS 对一致性的保证可以不受数据同步的干扰。
直观理解起来就是，数据量很大的数据流大家有力出力，全部都动员起来；而数据量小的控制流，则由持有租约的 chunkserver 自己决定，来单独负责写入的一致性保证。从而达到性能和一致性的均衡。

1,2. Client 向 Master 询问要写入 chunk 的租约在哪个 chunkserver 上 (Primary Replica)，以及其他副本 (Secondary Replicas) 的位置（通常 Client 中直接就有缓存）。
1. Client 将数据推送到所有的副本上，这一步就会用到流水线技术，也是写入过程中唯一的数据流操作。
1. 确认所有副本都收到了数据之后，Client 发送正式写入的请求到 Primary Replica。Primary Replica 接收到这个请求后，会对这个 Chunk 上所有的操作排序，然后按照顺序执行写入。
- →这里很关键，Primary Replica 唯一确定写入顺序，保证副本一致性。
1. Primary Replica 把 Chunk 写入的顺序同步给 SecondaryReplica。
- →注意，如果执行到这一步，Primary Replica 上写入已经成功了。
1. 所有的 Secondary Replica 返回 Primary Replica 写入完成。
1. Primary Replica 返回写入结果给 Client。
- →所有副本都写入成功：Client 确认写入完成
- →部分 Secondary Replica 写入失败（没有响应）：Client 认为写入失败，并从第 3 步开始重新执行。
如果一个写入操作涉及到多个 Chunk，Client 会把它们分为多个写入来执行。

GFS 的改写和追加

改写可以完全适配上面描述的写入的步骤，重复执行改写也不会产生副本之间的不一致。
但改写的问题在于一个改写操作可能涉及到多个 chunk。而如果部分 chunk 成功，部分 chunk 失败，我们读到的文件就是不正确的。
改写大概率是一个分布式操作，如果要保证改写的强一致性，代价就要大很多了。
论文中一再强调，GFS 推荐使用追加的方式写入文件，并且 Google 内部使用 GFS 的应用，它们的绝大多数写入也都是追加。

# 1.5.2 读取流程

client 收到读取一个文件的请求后，首先会查看自身的缓存中有没有此文件的元数据信息。如果没有，则请求 master (或 shadow master) 获取元数据信息并缓存。
client 计算文件偏移量对应的 chunk。
然后 client 向离自身最近的 chunkserver 发送读请求。如果在这个过程中，发现这个 chunkserver 没有自己所需的 chunk，说明缓存失效，就再请求 master 获取最新的元数据。
读取时会进行 chunk 校验和的确认，如果校验和验证不通过，选择其他副本进行读取。
Client 返回应用读取结果。

# 1.5.3 总结

B3. 怎样支持快速的顺序读和追加写？—— 总体上 GFS 是三写一读的模式。写入采用了流水线技术和数据流与控制流分离技术保证性能；追加对一致性的保证更简单，也更加高效，所以写入多采用追加的形式。读取则所有副本都可读，在就近读取的情况下性能非常高。

# 1.6 一致性模型

A4. 使用多副本的话，怎样保证副本之间的一致？
我们在讨论读写流程的时候，已经明确了维持副本间一致的基本方法，可以保证在单个写入的过程中，不会出现副本之间的不一致。
但在实际应用中，因为有多个 Client，我们的写入往往是并发执行的，这会带来副本间不一致的风险。
GFS 把文件数据的一致性大体上分为三个层次：inconsistent，consistent，defined。
- consistent：一致的。表示文件无论从哪个副本读取，读到的结果都一样。
- defined：已定义的。文件发生了修改操作后，读取是一致的，且 Client 可以看到最新修改的内容。（在 consistent 的基础上还能与用户最新的写入保持一致）
串行改写成功：defined。因为所有副本都完成改写后才能返回成功，并且重复执行改写也不会产生副本间不一致，所以串行改写成功数据是 defined。
写入失败：inconsistent。这通常发生在重试了一定次数仍无法在所有副本都写入成功时，意味着大概率有个副本宕机了，这种情况下一定是不一致的，Client 也不会返回成功。

并发改写成功：consistent but undefined。对于单个改写操作而言，成功就意味着副本间是一致的。但并发改写操作可能会涉及多个 chunk，不同 chunk 对改写的执行顺序不一定相同，而这有可能造成应用读取不到预期的结果。

追加写成功：defined interspersed with inconsistent（已定义但有可能存在副本间不一致）。
interspersed with inconsistent，追加的重复执行会造成副本间的不一致。
GFS 为了实现追加的一致性特性，对追加做了一些额外的限制：
- ①单次 append 的大小不超过 64MB。
- ②如果文件最后一个 chunk 的大小不足以提供此次追加所需空间，则把此空间用 padding 填满，然后新增 chunk 进行 append。
这样，每次 append 都会限制在一个 chunk 上，从而可以保证追加操作的原子性，在并发执行时也可以保证 Client 读取符合最新追加的结果。
并且，重复追加的问题相对来讲很好解决，比如文件原有的值是‘ABC’，追加‘DEF’。有的副本第一次失败再重复执行就是‘ABCDEF’，而两次都正确的副本是‘ABCDEFDEF’。但我们有很多手段可以在读取时仅读到一个‘DEF’，比如记录文件长度，比如各副本定期校验。

A4. 使用多副本的话，怎样保证副本之间的一致？——GFS 通过以下四种方式保证一致性

①对一个 chunk 所有副本的写入顺序都是一致的。这是由控制流和数据流分离技术实现的，控制流都是由 primary 发出，而副本的写入顺序也是由 primary 到 secondary。
②使用 chunk 版本号来检测 chunk 副本是否出现过宕机。失效的副本不会再进行写入操作，master 不会再记录这个副本的信息（等 Client 刷缓存时同步），GC 程序会自动回收这些副本。
③master 会定期检查 chunk 副本的 checksum 来确认其是否正确。
④GFS 推荐应用更多地使用追加来达到更高的一致性。

# 1.7 总结

回到 GFS 作为一个文件系统的本质，从最简单、最根本的角度回顾一下它。
对于外部应用而言，只需要把要读写的文件的相关信息传入 GFS 的 Client，Client 就会自动进行读写服务。除此之外，文件在 GFS 中是怎样保存的、会不会丢失（高可用性），文件总量快速增长怎么办、GFS 容量会不会不够用（可扩展性）等问题，使用 GFS 的应用都不用关心，因为 GFS 内部的存储设计和高可用设计，都可以基本保证对外部应用的读取没有功能上的影响（透明）。
但有一点需要注意：对 GFS 内部的数据，只有通过 GFS 的接口，也就是 Client 来读写，才能确保得到你想要的结果（或者说 “正确的” 结果）。因为 GFS 不仅会把文件拆成 64MB 的 chunk 分开存储，它们的位置全是自动分布的；并且 GFS 在读写的过程中还会对文件数据进行一些存储上的改动，这些改动（比如追加时的 padding）在通过 Client 读取时是不可见的，但是又确确实实存在于 GFS 的服务器上。
此外，使用 GFS 时还要注意尽量采用追加的方式写入。也就是说，GFS 希望你不要纠结于把文件修改掉，而是在文件最后写上改动后的内容，被修改的内容不去读取就好。
GFS 的快照 (Snapshot) 机制
需要快照的场景：保存文件的一个瞬时状态为另一个文件，用于备份或回滚。
快照的机制：COW（Copy On Write，写时复制）
①Master 回收对应 chunk 的租约，停止对应 chunk 的所有写入【停止文件 fileA 的写入】
②拷贝一份文件的元数据并命名为快照文件（快照文件的元数据仍指向原文件的 chunk）【拷贝文件 fileA 的元数据，生成 fileA_backup 元数据】
③增加文件所有 chunk 的引用计数【本来 fileA 的所有 chunk 引用计数都为 1，只有 fileA 引用，现在变为 2，fileA 和 fileA_backup 都引用】
④Master 正常授权租约，允许对 chunk 进行写入【开启文件 fileA 的写入】
⑤下次对文件进行修改时，发现其 chunk 的引用计数大于 1，修改时会先拷贝一个新 chunk，再在新 chunk 上写入。【fileA 的三个 chunk A B C，chunk C 有写入，那么写入时拷贝 chunk C 为 C' ，并写入 C' 。此时 fileA 指向 A B C'，fileA_backup 指向 A B C】

GFS 的 ** 垃圾回收 (GC)** 机制
需要 GC 的场景：
- ①客户端直接删除文件
- ②因丢失修改操作而失效的副本
- ③因 checksum 校验失败而失效的副本
GC 的机制：
- ①不立刻清除 chunk 的物理存储，而是修改文件的元数据，把文件名改为一个包含删除时间戳的、隐藏的名字。Master 会定期对 namespace 元数据进行扫描，当发现文件删除超过 3 天（可配置），就会把这个元数据删除掉。对应的 chunk 会走②③一样的流程删除。
- ②③Master 定期扫描各 Chunkserver 汇报的 chunk 集合，当发现没有对应文件元数据的 chunk（不被任何文件包含的 chunk）时，Chunkserver 就可以把这些 chunk 真正删除掉了。

从现在的视角看，GFS 也无疑是一个非常成功的系统。
从 GFS 论文发表以后，后续几乎所有的分布式文件系统，都或多或少借鉴了 GFS 的设计，有大量 GFS 的影子。比如目前非常常见的 HDFS，基本和 GFS 的架构完全一致。
此外，GFS 作为一个基础建设类型的底层文件系统，其作用不仅仅体现在其本身，还体现在在其基础上实现的系统。在 Google 内部，以 GFS 为基础搭建了 Bigtable，后续，又在 Bigtable 的基础上搭建出了 Megastore、Spanner 等系统。这些基于 GFS 的系统，也都在各自的领域取得了成功。作为金字塔最下层的基石，GFS 的架构在各方面都是相当完美的。在 Google 外部，有基于 HDFS 的 HBase，还有和 Spanner 类似机制的 TiDB，它们的身上都能看到 GFS 的影子。

# 云计算 期中

# 一、数据中心基础知识

# 1. 云计算的基本概念

# 1.1 定义与演化

# 1.2 特点

# 1.2.1 七大特点

# 1.2.2 NIS 云计算五大特征（最官方）

# 1.2.3 四个特征

# 1.3 分类：服务类型

# 1.3.1 无服务计算

# 计算：Lambda

# 1.3.2 无服务器计算的优点

# 1.4 分类：部署模式

# 1.4.1 公有云

# 1.4.2 私有云

# 1.4.3 混合云

# 1.4.4 社区云

# 1.4.5 总结

# 1.5 云计算发展现状

# 1.6 云计算实现机制

# 1.6.1 管理中间件

# 1.6.2 IaaS 实现机制

# 1.7 数据中心

# 1.7.1 云数据中心的特征

# 1.7.2 云数据中心网络诉求

# 1.7.3 区域和可用区

# 1.7.4 数据中心能源效率

# 1.8 云计算的核心理念

# 2. 习题

# 2.1

# 2.2

# 2.3

# 2.4

# 各选项分析

# 2.5

# 2.6

# 二、云计算中的操作系统

# 1. 虚拟化

# 1.1 概念

# 1.2 特点

# 1.3 分类

# 1.3.1 硬件虚拟化和容器化（图片背下来）

# 1.3.2 虚拟机管理程序（Hypervisor）

# 1.4 三种硬件虚拟化技术

# 1.5 容器化

# 1.6 实际

# 2. 多租户

# 2.1 概念

# 2.2 实现方式

# 2.3 Hadoop 实例

# 2.5 其他实例

# 2.6 其他虚拟化

# 3. 分布式系统

# 3.1 概念

# 3.2 特点与云计算

# 3.3 分布式应用

# 3.3.1 分布式计算

# 3.3.2 分布式存储

# 3.3.3 分布式资源管理

# 3.4 MapReduce

# 3.5 YARN & Hadoop

# 3.5.1 出现契机

# 3.5.2 设计理念

# 3.5.3 总体架构

# 3.5.4 控制流程

# 3.5.5 意义

# 4. 总结

# 三、云计算网络

# 1. 计算机网络基础

# 1.1 网络节点

# 1.1.1 集线器

# 1.1.2 交换机（Switch）

# 1.1.3 路由器（Router）

# 1.2 网络链路

# 1.3 网络类型

# 1.4 子网

# 1.4.1 概念

# 1.4.2 子网掩码

# 1.4.3 子网划分

# 1.5 网络体系结构

# 云计算期中