⑴ 云计算主要有哪几种类型
云计算通常可以分为三类：将基础设施作为服务（IaaS）、将平台作为服务（PaaS）和将软件作为服务（SaaS）。
1、IaaS：将硬件设备等基础资源封装成服务供用户使用。 在IaaS环境中，用户相当于在使用裸机和磁盘，既可以让它运行Windows，也可以让它运行Linux。 IaaS最大优势在于它允许用户动态申请或释放节点，按使用量计费。而IaaS是由公众共享的，因而具有更高的资源使用效率。
2、PaaS：提供用户应用程序的运行环境，典型的如Google App Engine。PaaS自身负责资源的动态扩展和容错管理，用户应用程序不必过多考虑节点间的配合问题。但与此同时，用户的自主权降低，必须使用特定的编程环境并遵照特定的编程模型，只适用于解决某些特定的计算问题。
3、SaaS：针对性更强，它将某些特定应用软件功能封装成服务。SaaS既不像PaaS一样提供计算或存储资源类型的服务，也不像IaaS一样提供运行用户自定义应用程序的环境，它只提供某些专门用途的服务供应用调用。
注意：随着云计算的深化发展，不同云计算解决方案之间相互渗透融合，同一种产品往往横跨两种以上类型。
⑵ 云计算主要有3种服务类型，每种类型的功能和服务对象都是什么
1、平台即服务（PaaS）
平台即服务是面向开发者的云计算。这种云计算最大的特征是它自带开发环境，并向开发者提供开发工具包。
2、软件即服务（SaaS）
软件即服务是普通消费者可以感知到的云计算，这种云计算最大的特征就是消费者并不购买任何实体的产品，而是购买具有与实体产品同等功能的服务。
3、基础架构即服务（IaaS）
基础架构即服务一般面向的是企业用户，这种云计算最大的特征在于，它出租的是服务器的计算能力和存储能力。
云计算的实现形式
云计算是建立在先进互联网技术基础之上的，其实现形式众多，主要通过以下形式完成：
（1）软件即服务。通常用户发出服务需求，云系统通过浏览器向用户提供资源和程序等。值得一提的是，利用浏览器应用传递服务信息不花费任何费用，供应商亦是如此，只要做好应用程序的维护工作即可。
（2）网络服务。开发者能够在API的基础上不断改进、开发出新的应用产品，大大提高单机程序中的操作性能。
（3）平台服务。一般服务于开发环境，协助中间商对程序进行升级与研发，同时完善用户下载功能，用户可通过互联网下载，具有快捷、高效的特点。
（4）互联网整合。利用互联网发出指令时，也许同类服务众多，云系统会根据终端用户需求匹配相适应的服务。
（5）商业服务平台。构建商业服务平台的目的是为了给用户和提供商提供一个沟通平台，从而需要管理服务和软件即服务搭配应用。
（6）管理服务提供商。此种应用模式并不陌生，常服务于IT行业，常见服务内容有：扫描邮件病毒、监控应用程序环境等。
⑶ 云计算环境下数据存储的特点
云计算是以分布式计算做为数据存储管理为基础的，所以宏观世界具有高容错、高可靠性、高可扩展性、高获得性、高吞吐率为特征。
⑷ 云计算块存储是什么，谁能给个解释呢
什么是块存储?
块存储与存储区域网络(SAN)是同义词，并且支持网络附加存储(NAS)系统中使用的文件存储技术无法实现的存储服务。块存储涉及将数据保存在块或原始存储卷中。
这些存储块中的每一个可以作为一个单独的硬盘驱动器出现在外部服务器操作系统上。操作系统依次使用光纤通道(FC)、以太网上的光纤通道(FCOE)或ISCSI协议来访问这些块。
块存储和SAN因此在企业IT环境中很普及的原因是由于其灵活性和性能特征。块存储支持各种需要低延迟、基于网络的存储操作的工作负载，其中包括业务关键型应用程序、虚拟机、RAID实施和数据库。
虽然不应该将其与文件存储系统混淆，这种类型使组织能够通过网络使用NAS-a文件系统为员工提供共享文件服务，可以将其分层存储在块存储上，因为块存储显示为原始存储到服务器操作系统。
在云平台中，块存储可从AWS ElasTIc Block Store或AWS EBS等服务获得，该服务提供可扩展块存储，供ElasTIc Compute Cloud(EC2)实例使用。
⑸ 云计算时代操作系统Kubernetes之存储（中）
我们在POD中定义数据卷的时候，必须指定数据卷的类型。由于存储技术的发展远远早于Kubernetes平台的诞生，并且随着Kubernetes的日益流行，新的存储技术和方案也在日新月异，因此数据卷可以说理所当然的有很多很多类型，有些是通用的类型，而有些需要底层特定存储技术的支持，下边是Kubernetes支持的数据卷类型不完全清单：
- emptyDir类型，emptyDir类型的数据卷允许POD将数据保存到指定的文件夹中，并且数据在POD的整个生命周期中可见。保存数据的文件夹在POD启动前被创建，并且刚开始文件夹为空，这也是叫empty的缘由。
- hostPath类型，从宿主机的文件系统挂载文件到POD中。
- nfs类型，NFS类型的存储卷挂载到POD中。
- cephfs，cinder，fc等，用来支持不同类型的网络存储。
- configMap，secret，downwardAPI，以及projected类型，四种卷类型，用来将POD和Kubernetes的相关信息通过文件暴露给外部，这些卷类型主要用来配置应用程序。这几种类型笔者会在后续的文章中详细介绍。
- persistentVolumeClaim类型（PVC），一种轻量级的集成外部存储能力的方案。在这种类型的数据卷类型中，PersistentVolumeClaim类型的存储对象指向PersistentVolume类型的存储对象，真实的外部存储系统由PersistentVolume这个对象来引用。由于这是Kuberntes强烈建议大家使用的存储类型，因此笔者会在后续的文章中，单独来详细介绍。
- csi类型，一种通过CSI来扩展存储的方式。这种方式允许所有实现了CSI（Container Storage Interface）接口的存储实现能够被POD引用，在POD初始化的过程中，CSI驱动会将存储卷attach到POD上。
上边罗列的只是数量巨大存储卷类型中很小一部分，每种类型都有对应的使用场景。笔者在本篇以及后续的文章中，着重介绍最具代表性的几个类型，来帮助大家理解Kubernetes存储体系。首先我们从最简单的emptyDir类型开始，这种类型的数据卷用来在容器重启场景中保持状态。
还记得我们在前边文章中介绍如何在同一个POD中部署两个容器实例的例子吗？当时的做法是通过post-start hook来执行fortune命令产生一个名言警句写入文件中，运行在另外一个容器中的Nginx服务器由于挂载了相同的volume，因此会直接将这个信息返回给客户端请求。这个保存fortune产生的名言警句的文件在容器的文件系统中，这就意味着当容器由于liveness probe三次失败重启后，你会看到不同的名言警句，虽然说看起来问题不大，但是从原理上讲，数据由于容器重启丢失。
我们来验证一下上边的推理是否符合事实，请在自己的本地环境中部署yunpan-fs.yaml，然后执行kubectl port-forward yunpan-fs 1080:80来创建客户端代理，访问服务返回名言警句。然后通过命令让Nginx重新启动，重新访问服务，你可以看到两次返回的数据不一致，这就证明了保存在容器文件系统的数据，在容器重启的场景下，不会保持。在笔者的本地环境输出如下图：
如上图所示，重启容器后会产生新的名言警句，这就意味着容器重启后保存在文件系统中的数据丢失了。如果我们要在这种重启的场景中保持数据状态，那么就必须确保数据被保存在数据卷中，而emptyDir是解决这个问题的完美方案。当emptyDir类型的数据卷被挂载到容器中，应用写到挂载目录的数据文件，在容器重启后，能够继续保持。
emptyDir类型的数据卷可以让容器即便是重启后，可以让写到文件中的数据状态保持；或者容器的文件系统为只读，但是应用在运行的过程中，需要写状态到文件中等场景，我们也可以使用emptyDir类型的数据卷来在同一个POD的多个容器之前，进行数据共享。
废话不多说了，咱直接修改fortune pod来把post-start hook执行fortune命令返回的名言警句写到emptyDir类型的数据卷中，这样当容器重启后，就不会出现数据丢失了。我们其实要修改的地方不多，主要包括：1，给POD增加emptyDir类型的数据卷定义；2，在容器中将这个数据卷挂载到指定的目录。
另外我们对命令的执行进行了一点点优化，post-start hook会在每次容器启动后都会执行，因此我们需要防止重启后对fortune命令输出对已经存在文件的覆盖，因此我们对post-start命令脚本也做了优化，如下图所示：
注：post-start hook脚本被更新成"ls /usr/share/nginx/html/quote || (apk add fortune && fortune > /usr/share/nginx/html/quote)"，如果读者对Linux shell脚本不是很熟悉，这句肯定看的云里雾里，我们来稍微解释一下。首先ls命令先执行，我们这里用ls来检查quote文件是否存在，你有所不值得是，当ls后边给的文件存在的时候，命令返回0，而如果不存在，就返回非0。由于我们使用||将两个表达式进行了组合，因此当左边的ls quote执行成功，那么右边的语句就压根不会执行。通过这种方式，如果quote文件存在，那么咱就直接跳过了。而当文件不存在，才需要执行右边的一串命令，安装fortune和执行fortune来产生名言警句。这句脚本确保名言警句只被生成并写入一次，也就是只在容器第一次启动的时候。
如上图所示，我们定义了emptyDir类型的数据卷content，并挂载到nginx容器指定目录/usr/share/nginx/html（这个是Nginx服务器默认用来扫描静态资源的目录）。在POD中配置volume需要提供配置参数，接下来我们详细聊聊如何配置emptyDir类型的数据卷。
对于emptyDir类型的存储卷，Kubernetes要求配置如下两个属性：
- medium，文件夹的存储介质，如果留空不配置，那么默认就是宿主机的（工作节点）磁盘。除了磁盘之外，我们还可以配置Memory，这会导致数据卷使用tmpfs文件系统，这是一个在内存文件系统。
- sizeLimit，文件夹需要的磁盘空间大小，比如我们如果需要限制这个文件夹中文件的大小为10M，那么就可以设置为10Mi。
注：我们上边的例子中，emptyDir类型的数据卷content未显示的定义任何字段，取默认值，大括号非常明确的表达了这一点，但是并不是必须的。
在POD中定义完数据卷只完成了工作的一半，工作的另一半就是将数据卷挂载到容器实例中，这通过在容器spec.containers域通过volumeMounts来引用。volumeMounts除了要制定name之外，还需要包含mountPath字段，来指定数据卷被具体挂载到容器文件系统的文件目录树的那个路径。笔者上边提供的例子中，emptyDir类型的数据卷被挂载到了/usr/share/ngxin/html目录，因为这也是post-start hook将名言警句写到文件的路径。
由于使用了emptyDir类型的数据卷之后，名言警句被写入到了宿主机的文件系统，因此数据在POD的整个生命周期都会保持，因此我们无论重启nginx容器多少次，返回的数据（名言警句）都不应该有任何变化。
接下来，我们将这个新版本基于fortune命令的名言警句网站部署到Kubernetes集群，并人为的让nginx容器重启，你会发现无论我们重启多少次，quote接口返回的内容都一样。背后的原理是，因为我们只在容器第一次启动的时候，才创建quote文件，并且当容器重启重新挂载数据卷后，这个quote文件仍然存在。你可能会问，这个文件到底在宿主机的啥地方啊，可以运行kubectl exec yunpan-emptydir -- mount --list | grep nginx/html来发现，如下图所示：
如上图所示，通过使用emptyDir类型的数据局content，我们成功让容器重启之后，保持数据状态。接下来，我们继续看另外一个例子，如何通过数据卷在两个容器时间共享数据。
如笔者前边多次提到，我们也可以使用emptyDir类型的数据卷来在同一个POD中的两个容器之间共享数据，这里需要注意的是，我们无法通过emptyDir类型的数据卷在不同PDO中不同的容器间共享数据，请继续阅读。
我们基于fortune的名言警句网站目前略显无趣，因为每次都返回相同的谚语，我们希望这个行为能够增强，比如每30分钟更换一次。为了实现这个功能，我们需要将post-start hook替换成容器，并且在容器中，fortune命令每30秒运行一次。为了使大家学习更加容易，笔者已经构建好了需要的容器，并上传到Docker Hub，大家可以自行通过命令 docker pull qigaopan/yunpan-fortune:v1.0拉取。
好了，我们已经把需要的容器镜像都准备好了，接下来我们来编写POD的YAML文件，如下图所示：
如上图所示，emptyDir类型的数据卷被两个容器共享（共同挂载），容器fortune将数据写到content数据卷，在nginx容器中，相同的数据卷被以read-only的模式被挂载到nginx的默认目录。
注：我们在前边文章中反复强调过一个事实，同一个POD中的多个容器几乎是同时启动的，因此可能存在微小的一段时间，ngxin服务器已经成功运行起来，但是quote文件尚未生成。聪明的你可能想到了，要避免这种场景，我们可以使用初始化容器。
接着，我们将fortune POD部署到Kubernetes集群中，两个容器几乎同时开始运行。fortune容器每30秒更新一次谚语（名言警句），nginx容器基于相同的数据文件服务客户端请求，当POD中的两个容器都Ready后，可以验证一下输出，是否每30秒后，quote请求对应的谚语的返回会更新。
由于在fortune例子中emptyDir类型的数据卷会在宿主机的磁盘上创建共享目录，因此数据读写的性能，完全取决于工作节点上硬件的类型。如果我们的应用需要高性能的IO操作，那么磁盘可能不是最合适的存储介质。
Kubernetes允许我们使用tmpfs文件系统来创建数据卷，而tmpfs将数据保存在内存中，我们只需要在POD的YAML文件中，把emptyDir的字段meim设置为Memory。
其实Memory类型的数据卷除了提供较高的IO之外，数据安全性也比磁盘高。由于数据并没有落盘，因此数据不容易被恶意攻击者窃取，因此建议大家可以在自己的项目上考虑这种数据卷类型。另外我们也可以通过参数sizeLimit来约束数据卷的size，特别对于Memory类型的数据卷来说，请务必设置sizeLimit，以防内存被耗尽。
在前边的内容中，我们将目光主要集中在如何在POD中定义数据卷，而没有详细介绍volume是如何挂载到容器中的，接下来我们来看看在容器中挂载数据卷具体需要设置哪些参数。如下图所示，是我们在新版本的fortune POD定义中关于content数据卷挂载的配置：
从上图可以看出，挂载数据卷到容器中，我们需要至少配置两个字段：name和mountPath，其中name字段是我们在POD定义的数据卷的名字，而mountPath字段指定了数据卷应该挂载到容器文件系统的文件数的那个目录。
除了这两个必须提供的参数之外，我们还有一些可选的参数可以配置，详细的可配置参数清单如下：
- name字段，如笔者上边的介绍，name字段就是我们在POD中挂载的数据卷的name
- mountPath字段，前文应介绍，不累述
- readOnly字段，是否以只读的模式挂载数据卷，默认是false，也就是以读写的方式挂载数据卷。
- mountPropagation字段，设置如果在数据卷内部挂载额外的文件系统会发生什么。有几个选项，默认是none，指如果宿主机在数据卷中挂在了额外的文件系统，容器不会收到任何通知，反之亦然；还有两个选项HostToContainer和Bidirectional，具体含义如命名，如果要了解详情，可以参考官方文档。
- subPath字段，默认为“”，意味着整个数据卷都被挂载到mountPath指定的目录，当设置为非空的字符串后，只有subPath指定的文件路径被挂载到容器中
- subPathExpr字段，使用类似于shell提供的$(ENV_VAR_NAME)语句，只能使用环境变量。
在大部分场景下，我们只需要设置name和mountPath就可以了，顶多额外多配置参数readOnly。mountPropagation参数只有在一些复杂配置的场景下才会用到，当我们用一个数据卷来提供不同的文件夹给不同的容器的时候，subPath和subPathExpr非常有用。另外这两个参数也可以用作多个PDO共享一个数据卷的场景。
好了，这篇文章的内容就这么多了，下篇文章我们继续介绍存储，看看如何访问宿主机文件系统中的数据文件，敬请期待！
⑹ 云存储结构模型大概是什么
朋友， 云存储系统的结构模型是由4层去组成。 1存储层 2基础管理层3应用接口层4访问层。其实云存储就是你可以随时随地，通过一些客户端方便自由地在不同电脑、手机、平板间达到同步数据；或者直接通过网络使用你存储的数据，比如直接观看在线视频，编辑文档。
云存储十分好用的，就相当于网络u盘，目前好用的云存储目前来说不会很多，像360云、网络云、天翼云都是不错的云存储。其中我就用过360云、天翼云，360云容量大，安全性好，速度也不错，而天 翼 云 ，有15G的初始空间，首次登陆其客户端就能一次性拿到10T，它有移动和pc的客户端，能同步数据，还支持在线视频，编辑文档等，也是一个不错的云存储。
⑺ 云存储架构分哪些层次,各自实现了什么功能
(1)存储层
云存储系统对外提供多种不同的存储服务，各种服务的数据统一存放在云存储系统中，形成一个海量数据池。从大多数网络服务后台数据组织方式来看，传统基于单服务器的数据组织难以满足广域网多用户条件下的吞吐性能和存储容量需求；基于P2P架构的数据组织需要庞大的节点数量和复杂编码算法保证数据可靠性。相比而言，基于多存储服务器的数据组织方法能够更好满足在线存储服务的应用需求，在用户规模较大时，构建分布式数据中心能够为不同地理区域的用户提供更好的服务质量。
云存储的存储层将不同类型的存储设备互连起来，实现海量数据的统一管理，同时实现对存储设备的集中管理、状态监控以及容量的动态扩展，实质是一种面向服务的分布式存储系统。
(2)基础管理层
云存储系统架构中的基础管理层为上层提供不同服务间公共管理的统一视图。通过设计统一的用户管理、安全管理、副本管理及策略管理等公共数据管理功能，将底层存储与上层应用无缝衔接起来，实现多存储设备之间的协同工作，以更好的性能对外提供多种服务。
(3)应用接口层
应用接口层是云存储平台中可以灵活扩展的、直接面向用户的部分。根据用户需求，可以开发出不同的应用接口，提供相应的服务。比如数据存储服务、空间租赁服务、公共资源服务、多用户数据共享服务、数据备份服务等。
(4)访问层
通过访问层，任何一个授权用户都可以在任何地方，使用一台联网的终端设备，按照标准的公用应用接口来登录云存储平台，享受云存储服务。
2云存储技术的优势
作为新兴的存储技术，与传统的购买存储设备和部署存储软件相比，云存储方式存在以下优点：
(1)成本低、见效快
传统的购买存储设备或软件定制方式下，企业根据信息化管理的需求，一次性投入大量资金购置硬件设备、搭建平台。软件开发则经过漫长的可行性分析、需求调研、软件设计、编码、测试这一过程。往往在软件开发完成以后，业务需求发生变化，不得不对软件进行返工，不仅影响质量，提高成本，更是延误了企业信息化进程，同时造成了企业之间的低水平重复投资以及企业内部周期性、高成本的技术升级。在云存储方式下，企业除了配置必要的终端设备接收存储服务外，不需要投入额外的资金来搭建平台。企业只需按用户数分期租用服务，规避了一次性投资的风险，降低了使用成本，而且对于选定的服务，可以立即投入使用，既方便又快捷。
(2)易于管理
传统方式下，企业需要配备专业的IT人员进行系统的维护，由此带来技术和资金成本。云存储模式下，维护工作以及系统的更新升级都由云存储服务提供商完成，企业能够以最低的成本享受到最新最专业的服务。
(3)方式灵活
传统的购买和定制模式下，一旦完成资金的一次性投入，系统无法在后续使用中动态调整。随着设备的更新换代，落后的硬件平台难以处置；随着业务需求的不断变化，软件需要不断地更新升级甚至重构来与之相适应，导致维护成本高昂，很容易发展到不可控的程度。而云存储方式一般按照客户数、使用时间、服务项目进行收费。企业可以根据业务需求变化、人员增减、资金承受能力，随时调整其租用服务方式，真正做到“按需使用”。
3云存储技术趋势
随着宽带网络的发展，集群技术、网格技术和分布式文件系统的拓展，CDN内容分发、P2P、数据压缩技术的广泛运用，以及存储虚拟化技术的完善，云存储在技术上已经趋于成熟，以“用户创造内容”和“分享”为精神的Web2.0推动了全网域用户对在线服务的认知
⑻ AWS云计算助手级架构师认证之EC2-存储类型
日常生活中经常用到的电脑存储类型，一般都是磁盘存储，如果使用的是Windows操作系统的话，就是C盘，D盘等。当我们使用EC2实例的时候，必须为该实例指定将在该实例上运行的数据保存在什么卷上。一般有两种存储类型，EBS卷存储，和实例存储卷（Ephemeral）存储。
EBS卷存储：
①EC2实例启动的时候，可以和EBS卷结合使用（作为根卷或者是附加卷），实例中使用的数据都会被永久性的保存在EBS卷上，实例停止（Stop）或终止（Terminate）后，数据仍然可以随着EBS卷保存下来（需要改变实例的EBS卷保留属性。EBS卷保留属性：当终止实例的时候是否保留使用的EBS卷）。
② EBS卷和EC2实例相连接的方式和日常生活中常见的电脑和硬盘的连接方式类似，单独买的硬盘，通过USB可以将硬盘和任意一台电脑相连接，不需要时可以拔下来。同样，EBS卷可以和不同的EC2实例相连接，但一个EBS卷一次只能和一个EC2实例相结合，而一个EC2实例可以和很多EBS卷相结合。EBS卷和EC2实例的连接方式是通过网络。
③EBS卷还可以以快照的形式将数据保存下来，待以后有需要时再还原成EBS卷。比如说我的EBS卷上有很多重要的数据，在别的EC2实例上也需要，那么我们可以通过对现在的EBS卷拍照，生成一个快照，然后再把该快照还原成EBS卷，最后把这个EBS卷和别的EC2实例相关联使用。需要注意的是，EBS卷是不能够跨区域（Region）使用的，当另外一个区域内的EC2实例想使用这个区域内的EBS卷的时候，必须对EBS卷拍摄快照，然后将生成的快照复制到另一个区域内才可以。
④有几个时机的注意点需要注意：当EC2实例启动的时候可以将EBS卷添加到EC2实例中，在EC2实例启动之后也可以把更多的EBS卷添加到EC2实例中。而卷保留属性，就是当终止运行的EC2实例时，是否删除该实例利用的EBS卷的一个属性，可以设置删除或者保留，而这个属性只能在启动EC2实例的时候设置。
实例存储卷（Ephemeral）存储：
① 当EC2实例和实例存储卷（Ephemeral）结合使用的时候（作为根卷或者附加卷），当EC2实例在运行状态下，实例中的数据会被保存在实例存储卷上，而当实例被停止（Stop）或终止（Terminate）的状态下，保留在实例上的数据会消失，（但对实例进行重启，即Restart的情况下，实例存储卷上的数据是不会消失的），也就是说保存在实例存储卷上的数据不是永久性的。但有别的方法将实例存储卷上的数据保存下来，方法就是对该实例生成一个AMI，然后利用该AMI启动实例，利用这个方法可以保存实例存储卷上的数据。
②有很多实例类型，但是并不是所有的实例类型都支持实例存储卷。实例和实例存储卷的连接方式是物理连接，其实实例存储卷是EC2实例物理主机上的磁盘存储卷。当AWS生成实例存储卷的是时候，它会利用保存在S3存储桶中的一个实例存储卷模板。在实例存储卷被完全生成之前，EC2实例是不会被启动的。而AWS生成EBS卷的时候，它会利用EBS快照。并且启动EC2实例时所需的部分EBS卷很少，只要从EBS快照恢复出来那一部分就可以完成启动EC2实例的动作。所以利用实例存储卷的EC2实例启动速度会比利用EBS卷的EC2实例的启动速度要慢。
③只有在启动EC2实例的时候才能把实例存储卷添加到EC2实例中，在启动EC2实例之后便不能再添加新的实例存储卷，这点和EBS卷是不同的。
注意：将实例终止或者停止之后再开始，则AWS可能会在不同的物理主机上启动新的实例，而将EC2实例重启的话，则是在同一个物理主机上。所以实例存储卷的数据在重启之后不会丢失，而在终止或停止之后则会丢失。并且当物理主机由于资源不足等错误造成EC2实例不能正常工作等致命错误时，最简单的方法就是将该EC2实例停止掉，然后再开始启动即可。
⑼ 云计算使得信息的储存是一个什么样的方式。
产品定义：
BC—oNest(Object Nest)是一个以对象形式存储和管理海量非结构化数据的云存储系统。BC—oNest可以为互联网业务和企业用户提供低成本的PB级存储规模，具备高可靠、高安全性和高扩展性的云存储服务。
产品实现了跨机架的海量对象存储和备份功能：提供WEB方问(业务使用门户以及REST API)以及SDK：提供批量导入导出工具来支持oNest和Linux本地目录之间的相互拷贝：支持Windows客户端工具，方便用户的使用。
产品特点
按需分配的存储空间：系统支持TB级到PB级的存储空间管理，存储容量可在线平滑扩容。
可靠的数据存储：系统支持对象数据跨机架存储；在每个AZ内多副本存储。系统的健康检查模块保证副本减少的情况下，自动修复副本数量：同时系统内部实现了数据的完整性校验机制，防止数据被非法篡改或损坏。
安全的数据访问控制：系统的认证鉴权和ACI一访问控制机制保证数据只被授权用户访问：同时系统支持密钥签名机制，保证用户访问消息在传输通道上的安全性。
高性能的数据处理：提供Multi Part的并发上传功能提高大对象上传速度：支持基于Range的多点并发下载功能提高对象下载速度：数据节点内部采用文件聚合的方法提高性能：支持高并发的用户访问和高吞吐的数据流量。
高可用的数据服务能力：AZ内多副本存储和副本自动修复能力，提高了系统持续服务能力，在常见的服务器集群节点或局部网络故障情形中，系统具有高可用性。
提供多种数据访问接口：系统对外提供WEB访问(业务使用门户及REST API)以及SDK，并提供批量导入导出工具来支持oNest和Linux本地目录之间的相互拷贝。
在服产品版本及特性:
5.X版本：
自主研发的以对象形式存储和管理海量非结构化数据的存储系统
基于跨机架的大规模数据中心环境设计，具有极强的水平扩展能力
提供类AWS S3的REST API和SDK，以及本地批量数据导入导出工具
支持用户、容器以及对象的访问权限管理和控制
服务可用性99.9%，数据可靠性99.999999999%，无单点故障，支持线性扩展
支持至少千亿级对象存储，单个对象最大5TB，千兆网络环境下4KB对象读取响应时间小于100ms
支持用户可选的服务器端及客户端数据加密存储，整个过程对用户透明
支持系统和存储资源监控及告警功能，易运营可管理
提供面向系统、用户和容器三个级别的准实时统计计量能力，支持用户按需付费
6.0版本：
基于主流ceph产品，支持纠删码，支持主流s3接口
核心功能：
1：对象相关功能
对象管理：系统支持对象的创建、读取和删除、设置用户自定义元数据等功能。
对象访问控制：系统支持设置或获取容器和对象访问权限(ACL)等功能。
2：容器相关功能
容器管理：系统按容器组织对象，每个用户可拥有零或多个容器，每个用户可包合零或多个对象。系统支持容器的创建、删除，按字典序列出容器内的对象等功能。
3：用户相关功能
用户认证及权限：对用户的身份进行认证，确认访问用户的身份，完成认证后基于用户状态、配额和权限进行确认。
4：系统相关功能
计量信息：提供为资源池管理系统提供计费需要的计量信息，包括空间占用、访问流量等。
用户控制：提供用户运营管理访问控制包括签约对象存储服务、查看对象存储服务等功能。
日志管理：提供对系统日志的记录及浏览功能。
统计报表：提供对系统各项指标的统计和分析，包括系统数据日志、用户日志及日志管理、访问统计、统计总空间占用、统计总用户数、统计各个节点上占用空间大小、容器总数量、流量信息统计等。
运维管理：提供云存储系统内部管理、维护，包括系统管理用户认证鉴权、系统管理角色管理、设备状态监控、设备维护等功能。
产品优势：
BC—oN est是基于标准X86服务器集群的对象存储系统。产品优势主要体现在：
容量和性能随节点增加而线性增强，且支持无缝的在线扩容和升级维护。
基于X86存储服务器的结构具有低成本特点。
系统的高可靠设计，单磁盘和单服务器故障不会影响系统服务，保障用户数据的可用性。
安全认证和数据加密手段，为用户提供安全的数据存储服务。
应用场景：
广泛应用于公众云存储服务，为用户和企业提供按需扩展的云存储服务。支持各类互联网应用，如网盘
类应用中对图片、文档和音视频的存储j对象存储通过与主流备份软件结合，可向用户提供更具成本效益、
更低TCO的备份方案j对象存储与归档软件、分级存储软件结合，可以将在线系统中的数据无缝归档／分级
存储到对象存储系统，减少阵列等在线系统存储资源。
应用案例：中国移动公众服务云
一：应用背景和面临的问题
云存储是laaS核心服务之一，主要支撑海量非结构化数据的存储和处理需求。传统的非结构数据存储系统主要采用磁盘阵列和NAS设备实现，为本地服务器提供块存储空间或文件存储空间，本质上属于数据中心内部的解决方案，主要存在的问题包括：首先，两者的服务接口协议上都不能满足在广域网范围提供服务的能力要求j其次，磁盘阵列和NAS设备的扩展I生也有限，不能满足百亿级文件的存储需求j最后，设备成本较高，基于阵列设备提供的云存储服价格不具备竞争性。
二：解决方案
公众服务云的对象存储服务使用BC—oNest产品实现。300台存储服务器可以提供PB级的对象存储服务空间支持百亿级的对象存储。
三：商业价值
中国移动公众服务云采用自主研发的BC—oNest，系统建设上相比使用商用解决方案节约成本数百万元。自主研发产品的应用也使得研发和运营实现紧密互动，对象存储服务的功能可随着市场竞争的要求实现快速迭代开发。
基于BC—oNest的对象存储服务是中国移动在公众服务云布局的重要环节之一，将为中国移动拓展行业云应用奠定坚实的基础。
欢迎拨打4001100865至中移软件技术有新公司咨询！
⑽ 云计算架构
云计算架构主要可分为四层，其中有三层是横向的，分别是显示层、中间件层和基础设施层，通过这三层技术能够提供非常丰富的云计算能力和友好的用户界面，还有一层是纵向的，称为管理层，是为了更好地管理和维护横向的三层而存在的。下面介绍每个层次的作用和属于这个层次的主要技术。
显示层
这层主要是用于以友好的方式展现用户所需的内容，并会利用到下面中间件层提供的多种服务，主要有五种技术：
HTML：标准的Web页面技术，现在主要以HTML4为主，但是将要推出的HTML5会在很多方面推动Web页面的发展，比如视频和本地存储等方面。
JavaScript：一种用于Web页面的动态语言，通过JavaScript，能够极大地丰富Web页面的功能，最流行的JS框架有jQuery和Prototype。
CSS：主要用于控制Web页面的外观，而且能使页面的内容与其表现形式之间进行优雅地分离。
Flash：业界最常用的RIA(Rich Internet Applications)技术，能够在现阶段提供HTML等技术所无法提供的基于Web的富应用，而且在用户体验方面，非常不错。
Silverlight：来自业界巨擎微软的RIA技术，虽然其现在市场占有率稍逊于Flash，但由于其可以使用C#来进行编程，所以对开发者非常友好。
在显示层，大多数云计算产品都比较倾向HTML，、JavaScript和CSS这对黄金组合，但是Flash和Silverlight等RIA技 术也有一定的用武之地，比如VMware vCloud就采用了基于Flash的Flex技术，而微软的云计算产品肯定会在今后使用到Silverlight。
中间件层
这层是承上启下的，它在下面的基础设施层所提供资源的基础上提供了多种服务，比如缓存服务和REST服务等，而且这些服务即可用于支撑显示层，也可以直接让用户调用，并主要有五种技术：
REST：通过REST技术，能够非常方便和优雅地将中间件层所支撑的部分服务提供给调用者。
多租户：就是能让一个单独的应用实例可以为多个组织服务，而且保持良好的隔离性和安全性，并且通过这种技术，能有效地降低应用的购置和维护成本。
并行处理：为了处理海量的数据，需要利用庞大的X86集群进行规模巨大的并行处理，Google的MapRece是这方面的代表之作。
应用服务器：在原有的应用服务器的基础上为云计算做了一定程度的优化，比如用于Google App Engine的Jetty应用服务器。
分布式缓存：通过分布式缓存技术，不仅能有效地降低对后台服务器的压力，而且还能加快相应的反应速度，最着名的分布式缓存例子莫过于Memcached。
对于很多PaaS平台，比如用于部署Ruby应用的Heroku云平台，应用服务器和分布式缓存都是必备的，同时REST技术也常用于对外的接口， 多租户技术则主要用于SaaS应用的后台，比如用于支撑Salesforce的Sales Cloud等应用的Force.com多租户内核，而并行处理技术常被作为单独的服务推出，比如Amazon的Elastic MapRece。
基础设施层
这层作用是为给上面的中间件层或者用户准备其所需的计算和存储等资源，主要有四种技术：
虚拟化：也可以理解它为基础设施层的“多租户”，因为通过虚拟化技术，能够在一个物理服务器上生成多个虚拟 机，并且能在这些虚拟机之间能实现全面的隔离，这样不仅能减低服务器的购置成本，而且还能同时降低服务器的运维成本，成熟的X86虚拟化技术有 VMware的ESX和开源的Xen。
分布式存储：为了承载海量的数据，同时也要保证这些数据的可管理性，所以需要一整套分布式的存储系统，在这方面，Google的GFS是典范之作。
关系型数据库：基本是在原有的关系型数据库的基础上做了扩展和管理等方面的优化，使其在云中更适应。
NoSQL：为了满足一些关系数据库所无法满足的目标，比如支撑海量的数据等，一些公司特地设计一批不是基于关系模型的数据库，比如Google的BigTable和Facebook的Cassandra等。
现在大多数的IaaS服务都是基于Xen的，比如Amazon的EC2等，但VMware也推出了基于ESX技术的vCloud，同时业界也有几个 基于关系型数据库的云服务，比如Amazon的RDS(Relational Database Service)和Windows Azure SDS(SQL Data Services)等。关于分布式存储和NoSQL，它们已经被广泛用于云平台的后端，比如Google App Engine的Datastore就是基于BigTable和GFS这两个技术之上的，而Amazon则推出基于NoSQL技术的Simple DB。
管理层
这层是为横向的三层服务的，并给这三层提供多种管理和维护等方面的技术，主要有下面这六个方面：
帐号管理：通过良好的帐号管理技术，能够在安全的条件下方便用户地登录，并方便管理员对帐号的管理。
SLA监控：对各个层次运行的虚拟机，服务和应用等进行性能方面的监控，以使它们都能在满足预先设定的SLA(Service Level Agreement)的情况下运行。
计费管理：也就是对每个用户所消耗的资源等进行统计，来准确地向用户索取费用。
安全管理：对数据，应用和帐号等IT资源采取全面地保护，使其免受犯罪分子和恶意程序的侵害。
负载均衡：通过将流量分发给一个应用或者服务的多个实例来应对突发情况。 运维管理：主要是使运维操作尽可能地专业和自动化 ，从而降低云计算中心成本。
负载均衡：通过将流量分发给一个应用或者服务的多个实例来应对突发情况。
运维管理：主要是使运维操作尽可能地专业和自动化，从而降低云计算中心的运维成本。
现在的云计算产品在帐号管理，计费管理和负载均衡这三个方面大都表现地不错，在这方面最突出的例子就是Amazon 的EC2，但可惜的是，大多数产品在SLA监控，安全管理和运维管理等方面还有所欠缺。
举例
接下来，将以Salesforce的Sales Cloud和Google的App Engine这两个着名的云计算产品为例，来帮助大家理解本文所提到的云计算架构：
Salesforce Sales Cloud
也就是之前的Salesforce CRM(客户关系管理)，属于云计算中的SaaS层，主要是通过在云中部署可定制化的CRM应用，来让企业用户在很低初始投入的情况下使用上CRM，并且 可根据自身的流程来进行灵活地定制，而且只需接入网络就能使用。在技术层面上大致的架构：
采用的主要技术：
显示层：基于HTML、JavaScript和CSS这对黄金组合。
中间件层：在此层，Salesforce引入了多租户内核和为支撑此内核运行而经过定制的应用服务器。
基础设施层：虽然在后端还是使用在企业环境中很常见的Oracle数据库，但是其为了支撑上层的多租户内核做了很多的优化。
管理层：在安全管理方面，Salesforce提供了多层保护，并支持SSL加密等技术，除此之外，其还在帐号管理、计费管理和负载均衡这三方面有不错地支持。
Google App Engine
App Engine属于云计算中的PaaS层，其主要提供一个平台，来让用户在Google强大的基础设施上部署和运行应用程序，同时App Engine会根据应用所承受的负载来对应用所需的资源进行调整，并免去用户对应用和服务器等的维护工作，而且支持Java和Python这两种语言。由 于App Engine属于PaaS平台，所以关于显示层的技术选择由应用的自身需要而定，与App Engine无关，关于App Engine在技术层面上大致的架构。
采用的主要技术：
中间件层：既有经过定制化的应用服务器，比如上面已经提到过的Jetty，也提供基于Memcached的分布式缓存服务。
基础设施层： 在分布式存储GFS的基础上提供了NoSQL数据库BigTable来对应用的数据进行持久化。
管理层：由于App Engine是基于Google强大的分布式基础设施，使其在运维管理技术方面非常出色，同时其计费管理能做到非常细粒度的API级计费，而且App Engine在帐号管理和负载均衡这两方面都有非常好地支持。
以上内容分析源自OFweek物联网，希望对大家有帮助。