云计算的知识梳理

一、云计算的定义：

官方：云计算是一种按使用量付费的模式（资源服务模式），该模式可以实现随时随地、便捷按需的从可配置资源共享池中获取所需的资源。包括网络、服务器、存储、应用及服务，资源能够快速供应并释放，大大减少了资源管理工作的开销。

：云计算 是基于互联网的相关服务的增加、使用和交付模式，通常涉及通过互联网来提供动态易扩展且经常是虚拟化的资源。

特点：1超大规模 2虚拟化 3高可靠性 4按需服务 5高可扩展性

二、OpenStack的历史版本：

云计算：2010年 元年，因为出现了OpenStack的第一个版本Austin（2010-10-21），目前已经到最新版本Queens,前一个版本是Pike版本，发行版本的规律：字母表顺序A-Z来命名的

三、OpenStack的难点在哪里？

1、OpenStack涉及的知识领域极广

2、OpenStack是一个平台，并不是一个具体的实施方案

OpenStack的Cinder（存储服务）定义了上层API，分布式存储软件，Ceph、HDFS对应的驱动

3、OpenStack本身是一个分布式系统：All-in-one部署

对于一个小白来说，OpenStack的搭建无疑是一个痛点，这个门槛有点高，我在开始学习的时候，也是煞费苦心，所以学好基础知识真的非常重要。

四、什么是虚拟化？

1）、虚拟化与虚拟化技术是什么？

虚拟化是云计算的基础，

虚拟化：软件模拟硬件的过程

具体定义：虚拟化使一台物理机上可以跑多台虚拟机，虚拟机共享物理机的CPU、内存、IO等硬件资源，每一台虚拟机逻辑上是相互隔离的。

行业内专用术语：

1、物理机：宿主机Host

2、虚拟机：客户机Guest

2）、虚拟化分类（按照虚拟化实现结构）：

1、1型虚拟化

定义：Hypervisor直接安装在物理机（裸机）上，多个虚拟机在Hypervisor上运行。

特点: 1型虚拟机本身就是一个操作系统，不需要其他操作系统的支持

举例：VMware的ESXI（workstation、server）

2型虚拟化

    物理机上首先安装常规的操作系统，比如 Redhat、Ubuntu 和 Windows。Hypervisor 作为 OS 上的一个程序模块运行，并对管理虚拟机进行管理。KVM、VirtualBox 和 VMWare Workstation 都属于这个类型。

虚拟化技术：一种运行在基础物理服务器和操作系统之间的中间软件层，可以访问服务器上包括磁盘和内存在内的所有物理设备。Hypervisor协调着这些硬件资源的访问，以及各个虚拟机之间的防护。服务器启动时，它会加载所有虚拟机客户端的操作系统，同时为虚拟机分配内存、磁盘和网络等。也可叫做VMM（ virtual machine monitor ），即虚拟机监视器。

1型和2型虚拟化的对比：

1、前者性能比后者好

2、前者不需要操作系统支持，后者需要

3、后者更加灵活，特点：支持虚拟机的嵌套

使用虚拟化的原因：

打破实体结构间不可切割的障碍，使用户能更好的利用这些资源

没有虚拟化:服务器的IT资源30%

有虚拟化：服务器的IT资源70%

3）、虚拟化的优点

1、提高IT资源利用率

2、显著减少了服务器的数量，企业不动资产和管理成本。

3、加速应用部署

4、提高应用兼容性

五、云计算服务三层架构：根据提供服务的不同（会在下一篇详细讲解三种服务）

1、IaaS:infrastructure as a Service

定义：基础服务层

功能：提供的服务是存储、计算、网络等硬件资源  OpenStack

特点：负责管理虚拟机的整个生命周期，虚拟机创建、修改、启动停止、快照/备份、销毁

举例：阿里云、腾讯云、亚马逊的AWS（Amazon webserice）

2、PaaS：platform as a service

定义：平台服务层

功能：提供的服务是应用程序的运行环境和一系列中间件服务

特点：负责保证服务的性能和可用性。

举例：大数据和深度学习容器云平台

3、SaaS：Software as a service

定义：软件服务层

功能：提供的服务是软件/应用程序。

特点：用户需要登录并使用它，"拿来即用"

举例：facebook、twitter、instagram、QQ、微信

网上还有人说Docker的CaaS（container as a service）容器服务层。

六、OpenStack是什么？

OpenStack is a cloud operating system that controls large pools of storage, compute,and networking resources throughout a datacenter,all managed through a dashboard that gives administrators control while empowering their users to provision resources through a web interface。

官方定义：OpenStack是一个（可以管理整个数据中心里存储、计算及网络资源的）云操作系统。

OpenStack 作为一个操作系统，管理资源是它的首要任务；

OpenStack 管理资源主要有三个方面：计算、存储和网络。

整个OpenStack是由控制节点，计算节点，网络节点，存储节点四大部分组成。这四个节点也可以安装在一台机器上，单机部署（All-in-one部署）

控制节点 负责对其余节点的控制，包含虚拟机建立，迁移，网络分配，存储分配等等

计算节点 负责虚拟机运行

网络节点 负责对外网络与内网络之间的通信

存储节点 负责对虚拟机的额外存储管理等等

下面我给出一张官方架构图（给出中文版方便理解）：

OpenStack的组件：

Nova：计算管理服务，提供了对计算节点的Nova的管理，使用Nova-API进行通信 （核心服务）

Neutron：网络管理服务，提供了对网络节点的网络拓扑管理，同时提供Neutron在Horizon的管理面板（核心服务）

Glance：镜像管理服务，提供了对虚拟机部署的时候所能提供的镜像的管理，包含镜像的导入，格式，以及制作相应的模板（核心服务）

Keystone：认证管理服务，为OpenStack的其他组件提供认证（auth）服务 （核心服务）

Cinder：提供管理存储节点的Cinder相关（为虚拟机提供存储卷（虚拟硬盘）） （核心服务）

Swift：为Glance和Cinder提供对象存储服务

Ceilometer：为OpenStack提供监控（monitor）、计量服务；提供对物理资源以及虚拟资源的监控，并记录这些数据，对该数据进行分析，在一定条件下触发相应动作

Heat：提供了基于模板来实现云环境中资源的初始化，依赖关系处理，部署等基本操作，也可以解决自动收缩,负载均衡等高级特性。

Horizon：控制台服务，提供了以Web的形式对所有节点的所有服务的管理  （核心服务）

第一次写关于技术方面的文章，不足之处后面还会修改补充，希望自己坚持下去。

1云计算存储开发

2003年，谷歌发表论文GFS，披露解决了索引地球的海量互联网数据的存储问题。2006年，亚马逊推出了划时代的AWS云计算服务EC2和S3，开启了改变世界IT格局的云计算时代。谷歌，微软，阿里云等。都跟着。

上面提到的A Bite os S3 Arch如何构建一个分布式存储系统来支持大规模S3对象存储。云计算还有另外两个重要的基础存储基础架构组件EBS(弹性块存储)和EFS(弹性文件服务)，分别对应传统IT基础架构中的本地磁盘和共享文件存储服务。

云计算很重要的一点就是超卖和灵活性，所以支持EBS和EFS方案的底层基础存储层的支持不太可能是本地本地化方案，必须是分布式的存储资源管理和分配系统。

然而，与S3服务相比，EBS底层的分布式存储系统提供的IO模型实际上有很大不同。S3的基本外部接口功能是PUT/GET/DELETE，它对底层分布式文件系统的要求是Append。EBS和EFS需要支持对用户随机地址空间的重写，那么如何设计底层存储系统来支持这两类服务呢？

对于这一块的业务架构，目前各大互联网公司基本都没有开源，基本架构也没有或者很少正面出来。这一方面可能被视为商业秘密，另一方面可能从安全、舆论等方面考虑。

当然，开源系统的论文和一些互联网公司的存储系统可以参考，比如ceph、Lustre、HDFS、GlusterFS、FastDFS、Window Azure Storage、GFS等等。这些都称自己为分布式文件系统，但是在具体的场景和文件的定义上有很多不同。以下几个方面差别很大。

EBS底层的分布式存储系统至少需要确保以下几点

EBS底层分布式存储系统需要提供上述重要特性，还有一些重要的核心需求。

那么如何设计和构建EBS底层的分布式存储系统来满足业务的需求，也就是如何设计一个向上层业务提供随机IO能力的分布式存储系统。这里有一些可能的方法来建立它。

对于EBS业务，抽象地说，需要底层分布式文件系统提供可以随机读写的文件的能力。按照最直接的方式，可以如下图逻辑映射。1TB Vdisk /dev/sad对应的是底层分布式文件系统为/foo/sda的文件。1TB地址空间上的chunk是按需分配的，分配的基本单元一般是固定的，如下图，4MB。

Qemu等。提供了对接块设备驱动的API，只要在分布式文件系统对接对应的客户端实现API，块设备就可以向上输出。

网易实现了这种从0到1的构建方式。CURVE现在是开源的(百度类似于这个方案)，底层抽象为典型的分布式文件系统，向服务输出具有随机读写能力的文件，以支持上层块设备的EBS类型服务。架构基本类似于经典分布式文件系统的鼻祖GFS，如下图所示。

基础设施

数据表面核心

底层ChunkServer基于Raft)状态机来实现副本一致性。有关详细信息，请参见Raft对等复制状态机。所有上层用户的写入都依赖于一致性协议来确保多个副本的一致性，每个用户的区块都分配给这些复制组。

如上图所示

这种架构方案优点是：

该方案的缺点：

上述构建模式1是一种0对1的架构设计和实现。第二种构造方法主要是和圈内的童鞋沟通，细节无法研究，但从整体结构层面解释分析没有大问题。

其基本架构类似于Window Azure Storage的架构。Stream层构建在底层，Partition层构建在Stream层的基础上(类似GFS)，EBS方案可以构建在Partition层的基础上(类似BigTable)。

如何支持基于这种架构的服务，需要从另一个角度思考如何解决这个问题。回到问题的出发点，EBS随机地址空间读写方案的核心是什么问题？

简单来说，块设备提供对每个地址空间(比如4KB)的原子读写(PUT/GET)。换句话说，如果为每个EBS实例的每个4KB内容定义了一个全局可编码的惟一键，那么它的内容就是4KB的固定大小值。那么底层的分布式存储系统就是一个专用的分布式键值系统。

构造方法2基本上遵循这样的思想。

作为上面的基本逻辑视图示例，底层物理层结构如下图所示。

StreamLayer:类似于GFS/HDFS层次结构，每个流类似于一个文件，流只支持append。Stream由盘区组成(类似于HDFS/GFS的chunk)，盘区使用固定复制组的方案实现多个副本/EC(参考微软PacificA协议)。范围支持可变长度。当盘区不可用时，seal/new创建一个新的盘区继续提供写入，以保证写入的高可用性。

分区服务器：提供一段表(根据字典

序分裂）的kv 存储服务（增/删/改/查）。其通过WAL实现数据的快速和及时写入，保障数据的持久性；然后写入MemStore（SkipList跳表实现），在MemStore达到固定大小，比如128MB的时候Dump成SSTable（Sorted String Table），Block Cache 负责SStable 热点数据的读缓存。一个Partiton Server 负责多个Partition。

架构方面的更加具体的参考Window Azure Storage 的paper或者BigTable开源实现方面的书籍和资料，这里不多做展开。

在实际操作层面，对于一个上层的EFS实例，有挺多的映射关系：

一般来说为了实现EFS的快照和克隆功能，一个EFS实例一般都选择一个table。如果是只有一个WAL，写入的吞吐容易受影响，可以在上层使用一定的间接的业务逻辑手段使得多个相邻的地址空间换分到不同的Region，从而把上层IO映射到更多的Region，使用多个WAL写入能力提升带宽。比如将地址空间按照1MB取模划分到4个独立的连续字典序区间Region。

此种构架方案的优点：

反脆弱：这是这种方案我认为最最大的优点，也是相比方案一的绝对杀手锏，很多分布式存储系统其实从 基层层面都没有好好考虑这个问题，或者到意识到这种方案的巨大优势。即从读层面WAS基本实现了 已经seal 数据的任何副本是可读的。对于写数据来说，由于写入只限制在当前 尚未seal 掉的chunk上，也就是3个磁盘上，并且在故障情况下随时可以seal掉转移。这两点使得虽然 上层一个table的数据打散到底层这么多磁盘上。但是从爆炸半径来说，基本上算是实现了本地盘方案的爆炸半径，甚至在故障，过载情况下可以实现快速转移。从这点上来说，这样基本为分布式存储方案去完全干掉本地存储方案，打下了极其坚实的基础。

此种构建方案的缺点：

构建方案3类似方案2的变种。核心的不同点在于，构建方案2的全局排序和垃圾回收工作依赖于后期的compaction。而构建方式3倾向于尽可能块得进行原地排序。

其基本原理是，通过WAL 写入确保数据持久性，然后使用到内存。后台定期将写入原地使用到随机读写文件（没错，底层除了需要实现AppendFile，还需要实现弱一致的随机读写文件RandomFile，多幅本的数据一致性由Client负责，这引入一个缺点，随机读写文件很难做EC），WAL使用seal-new的方式确保写入可用性，读取采用Merge 更新数据（wal） 基线数据（随机读写文件数据）的方式实现数据的读取。在内存中建立对整个WAL内容的索引，最新的数据在WAL中则直接从WAL中读取，否则从随机读写文件中读取，其基本读写流程图如下

写入：写入还是一样写入WAL，然后更新内存索引，将最新数据的使用MemTable(Hash表)指向WAL。但是最终结果的Dump其实并不是按照sstable的方式，而是直接后台异步dump到对应RandomFile的随机地址空间。

PS1：WAL 也是类似Segment方式，定期做checkpoint（刷入RandomFile），在内存中会构建所有WAL segment的索引，WAL采用Seal/New的方式来保障可用性。

PS2: RandomFile是随机读写文件，为了保障WAL长度的收敛性，后台线程会将WAL数据写入RandomFile。RandomFile 没法使用Seal-New的可用性，但是由于是BackGround的写入。所以如果发现一个副本失败，会使得BackGround dump机制阻塞（这种方案在坏盘恢复场景下，会导致BackGround写入会卡很久）。

读取: 读取会首先通过Memtable查找最新数据是否在WAL中，不存在的情况下再读RandomFile。对于RandomFile未达到一致性状态的数据，会从WAL里头进行读取。（PS:由于WAL(AppendFile) 到 RandomFile的写入是全三副本，并且一直是卡着的，所以RandomFile的恢复可以采用很鲁棒的方式，直接选中任意一个还在复制组中的副本作为数据源复制。)

这种方案可以一定程度解决。读放大、空间利用率等方面的问题。但是在克隆、快照等方面会稍微差一些，并且随机读写文件很难做EC（EC改写好麻烦）。

如上对3种构建方式进行了简要的构建和优缺点的说明。没有绝对的那个构建方案优于另外一个构建方案。在实践过程中应结合自身面向的实际业务特点和技术条件等进行选择，能快速跟上业务发展并且对方案做中长期的评估适时进行调整。

很重要一点是一定得进行抽丝剥茧、形而上得分析问题的本质。这样才能够把精力集中在真正的问题上，好钢放在刀刃上。

简单来说，块设备提供了对每一个地址空间（比如4KB）的原子写入和读取(PUT/GET)。换一个角度来说如果对每一个EBS实例的每一个4KB内容定义一个全局可编码的唯一Key，其内容为4KB的固定大小的Value。那么这个底层分布式存储系统就是一个专用的分布式Key-Value系统。

以上不同的方案，从逻辑上往上抽象都可以认为是向业务提供KV存储。最本质的区别可以认为是排序在什么时候进行。构建方案1总体来说是即刻全局排序。构建方案2 则采用局部有序的方案。而架构方案3则 使用架构方案1和方案2 的折中。

另外一个很重要的差别是从核心可靠性的角度来说，构建方案1采用了多数派（如Raft）方案应对分布式的CAP问题。而构建方案2、3采用PrimayBackup Master（多数派） Append Only的特点来应对CAP问题。

相关问答：EBS在PVC制品中的添加效果？急急急求回答！！！？？由于ebs分子存在极性酰胺基团，因此它与pvc树脂有一定的相容性，在加工过程中ebs可以插入pvc树脂内部，降低树脂分子间的摩擦力，避免糊料达到防粘作用。但总体来说，ebs与pvc树脂相容性有限，可以由树脂内部牵引到表面，主要起到外润滑剂的作用，可避免过高剪切应力，降低剪切热，减小物料与加工设备之间的相互摩擦，防止物料黏附设备，从而提高制品的尺寸精度，提高制品的表面光泽度。

云服务器和普通服务器主要区别有三点：

1、定义不同：

云服务器，是简单高效、安全可靠、处理能力可弹性伸缩的计算服务，是一个服务器集群。

普通服务器是一个服务器，位置相对固定，是提供计算服务的硬件设备。

2、配置不同：

云服务器无需提前购买硬件，即可迅速创建或释放任意多台云服务器，一切计算均在云端实现，降低开发运维的难度和整体IT成本。

普通服务器的构成包括处理器、硬盘、内存、系统总线等，和通用的计算机架构类似，费用成本较高。

3、故障率不同：

云服务器是基于服务器集群的，因此硬件冗余度较高，故障率低。

而物理机则相对来说硬件冗余较少，故障率较高。

扩展资料：

云服务器的优点：

1、云计算服务器，有效地解决了传统物理租机与VPS服务中，存在的管理难度大，业务扩展性弱的缺陷。

2、用户可以方便的进行远程维护，免费重装系统 硬件级别上实现云主机之间的完全隔离；内置冗余的共享存储和智能备份，物理服务器失败可在几分钟内自动恢复。

3、具有快速供应和部署能力，用户在提交云主机租用申请后可实时开通，立即获得服务， 业务支持平滑扩展，当用户业务规模扩张时，可快速实现业务扩容。

-云服务器

-服务器