㈠ 云存储的底层关键技术有哪些
一切以客户的需求为出发点。传统存储以文件系统为典型代表，但是随着数据爆炸性增长，传统文件系统已经无法满足对存储系统的容量、性能等需求，因此，云存储应运而生。云存储最大的特点是数据被集中存储在数据中心，公有云存储将客户数据存放在公有云服务商数据中心，而私有云存储则是将公有云存储能力私有化部署在客户自身的数据中心。既然提到了数据中心，可想而知云存储最大的特点应该是海量：解决数以PB至EB的数据存储需求。所有云存储技术面对的通用问题有如下几个：
扩展性：即容量可以通过横向增加服务器、磁盘等线性扩展，软件不应该成为限制扩展性的瓶颈；
可靠性：如何保证数据不丢失，或者丢失概率极低；
可用性：如何保证数据always online；
性能：不同的客户的不同使用场景对云存储性能提出不同需求。
㈡ 如何在AWS S3存储段中设置CloudFront分布
AWS CloudFront是一个用户用于加速静态或动态内容发布的内容发布服务，这里所谓的静态或动态内容主要包括媒体（图像或视频）文件、HTML、Java脚本程序、CSS文件以及其它。
作者：文:Ofir Nachmani 译:滕晓龙来源：TechTarget中国|2015-03-09 10:12
收藏
分享
AWS CloudFront可配合一些其他的服务一起使用，其中就包括了EC2和S3。遵循以下步骤可从一个S3存储段中设置一个CloudFront分布。
AWS CloudFront是一个用户用于加速静态或动态内容发布的内容发布服务，这里所谓的静态或动态内容主要包括媒体（图像或视频）文件、HTML、Java脚本程序、CSS文件以及其它。它的简洁用户界面可以帮助管理员设置CloudFront发布。但是，这一过程并不只是指向和点击那么简单。下面，就让我们来看看CloudFront的工作原理以及应当如何来部署它。
在CloudFront中，每一片的内容都被组织成为具有独特URL并可从网络被访问的发布。该服务可从边缘加速节点数据中心发布这一内容；目前，AWS在全球部署着52个边缘加速节点数据中心以供内容缓存使用。
AWS CloudFront支持两种形式的发布：流形式与下载方式。当一名用户使用CloudFront URL来请求静态内容时，该服务就会根据发出请求的IP以及缓存这一内容的数据中心的位置来找到距离这个IP最近的边缘加速节点数据中心。这样一来，所有来自于相同位置的请求就会减少延迟时间。
CloudFront可配合多个AWS服务使用，其中包括了简单存储服务（S3）、弹性计算云（EC2）、弹性负载平衡（ELB）以及Route 53。CloudFront的主要功能包括：
支持动态内容（减少未来请求的延迟时间）
支持自定义域名
设备检测（移动设备和网络设备）
支持Post/PUT以及其它的HTTP协议
自定义错误响应
支持cookies、查询字符串以及其它
链接一个CloudFront发布至S3
为了从一个S3建立一个CloudFront网络发布，你将需要一个S3存储和一个可公开访问的对象（如图1）。
图1 S3存储段以及一个可公开访问的对象
然后，可遵循以下步骤：
1. 转至CloudFront并创建一个网络发布
图2 选择初始域名存储段
2. 在初始域名栏位，选择存储段名称，并在限制存储段访问中选择“No”。这样做可以限制只能从CloudFront访问对象，所以就没有人可以从S3访问这个存储段了（如图2）。
3. 使用以下参数配置缓存设置：
路径模式：默认。针对特定对象应用缓存处理。如果选择了默认值（*），它就会把所有请求发送到选中的存储段中。
浏览器协议策略：HTTP 和 HTTPS。如果用户想要求CloudFront允许浏览器使用HTTP或HTTPS协议来访问用户的网络内容。
允许的HTTP方法：GET，HEAD。选择用户希望这一缓存操作所允许的HTTP方法列表。
转发头文件：None。如果用户希望根据请求中发送的头文件来缓存内容，那么就可以使用它。理想情况下，保持“None”项是可以提高性能的。
对象缓存：使用初始缓存头文件。当你的初始服务器将增加一个缓存控制头文件以便于控制对象被保存在CloudFront缓存中多长时间时，可选择这一选项。
转发cookies：无。如果用户希望CloudFront在它发送给初始服务器的请求中囊括所有的用户cookies，那么就可以指定“None”。否则，可指定你希望包含在内的cookies。选择“None”，就可配置CloudFront不要发送cookies。
转发请求字符串：不。为了根据URL中的请求字符串获得不同版本的对象；设置“Yes”选项以便于在发送给初始服务器的请求URL中包含请求字符串。
限制浏览器访问：No。在理想情况下，选择“yes”以提高安全性。选择“no”可让每个人都能够查看内容。限制浏览器访问意味着要求使用者为安全访问而创建一个签名的URL（如图3）。
图3 限制浏览器访问
4. 接下来，是设定发布设置
价格类别：使用所有的边缘加速节点数据中心。这一操作可以让用户自行选择愿意为CloudFront服务支付的最高价格。
CNAMEs：空白。这一操作可以允许用户为对象使用URL而不是CloudFront分配的域名。因此，用户可以指定一个自定义URL，而不是CloudFront发布。
SSL证书：默认CloudFront。这一项可以让管理员上传他们自己的证书。用户还可以保留其它的选项作为默认值，并创建发布（如图4）。
图4默认的CloudFront设置。
一旦创建了发布，那么你将有一个CloudFront URL，例如："http://d3ptzllcr53x1i.CloudFront.net＂。然后，就可以使用这个URL来访问对象了。
㈢ openstack的问题。
OpenStack其实有三个与存储相关的组件，这三个组件被人熟知的程度和组件本身出现时间的早晚是相符的，按熟悉程度排列如下：
Swift——提供对象存储 （Object Storage），在概念上类似于Amazon S3服务，不过swift具有很强的扩展性、冗余和持久性，也兼容S3 API
Glance——提供虚机镜像（Image）存储和管理，包括了很多与Amazon AMI catalog相似的功能。（Glance的后台数据从最初的实践来看是存放在Swift的）。
Cinder——提供块存储（Block Storage），类似于Amazon的EBS块存储服务，目前仅给虚机挂载使用。
（Amazon一直是OpenStack设计之初的假象对手和挑战对象，所以基本上关键的功能模块都有对应项目。除了上面提到的三个组件，对于AWS中的重要的EC2服务，OpenStack中是Nova来对应，并且保持和EC2 API的兼容性，有不同的方法可以实现）
三个组件中，Glance主要是虚机镜像的管理，所以相对简单；Swift作为对象存储已经很成熟，连CloudStack也支持它。Cinder是比较新出现的块存储，设计理念不错，并且和商业存储有结合的机会，所以厂商比较积极。
Swift
关于Swift的架构和部署讨论，除了官方网站，网上也有很多文章，这里就不重复.(也可以参考我之前在OpenStack中国行活动中上海站演讲的PPT)。从开发上看，最近也没有太大的结构性调整，所以我想主要说说比较适用的应用领域好了。
从我所了解的实际案例来看，Swift出现的领域有4个，(应该还有更多，希望大家看到实际用例能够指教)
1.网盘。
Swift的对称分布式架构和多proxy多节点的设计导致它从基因里就适合于多用户大并发的应用模式，最典型的应用莫过于类似Dropbox的网盘应用，Dropbox去年底已经突破一亿用户数，对于这种规模的访问，良好的架构设计是能够支撑的根本原因。
Swift的对称架构使得数据节点从逻辑上看处于同级别，每台节点上同时都具有数据和相关的元数据。并且元数据的核心数据结构使用的是哈希环，一致性哈希算法对于节点的增减都只需重定位环空间中的一小部分数据,具有较好的容错性和可扩展性。另外数据是无状态的，每个数据在磁盘上都是完整的存储。这几点综合起来保证了存储的本身的良好的扩展性。
另外和应用的结合上，Swift是说HTTP协议这种语言的，这使得应用和存储的交互变得简单，不需要考虑底层基础构架的细节，应用软件不需要进行任何的修改就可以让系统整体扩展到非常大的程度。
2.IaaS公有云
Swift在设计中的线性扩展，高并发和多租户支持等特性，使得它也非常适合做为IaaS的选择，公有云规模较大，更多的遇到大量虚机并发启动这种情况，所以对于虚机镜像的后台存储具体来说，实际上的挑战在于大数据（超过G）的并发读性能，Swift在OpenStack中一开始就是作为镜像库的后台存储，经过RACKSpace上千台机器的部署规模下的数年实践，Swift已经被证明是一个成熟的选择。
另外如果基于IaaS要提供上层的SaaS 服务，多租户是一个不可避免的问题，Swift的架构设计本身就是支持多租户的，这样对接起来更方便。
3.备份归档
RackSpace的主营业务就是数据的备份归档，所以Swift在这个领域也是久经考验，同时他们还延展出一种新业务--“热归档”。由于长尾效应，数据可能被调用的时间窗越来越长，热归档能够保证应用归档数据能够在分钟级别重新获取，和传统磁带机归档方案中的数小时而言，是一个很大的进步。
4. 移动互联网和CDN
移动互联网和手机游戏等产生大量的用户数据，数据量不是很大但是用户数很多，这也是Swift能够处理的领域。
至于加上CDN，如果使用Swift，云存储就可以直接响应移动设备，不需要专门的服务器去响应这个HTTP的请求，也不需要在数据传输中再经过移动设备上的文件系统，直接是用HTTP 协议上传云端。如果把经常被平台访问的数据缓存起来，利用一定的优化机制，数据可以从不同的地点分发到你的用户那里，这样就能提高访问的速度，我最近看到Swift的开发社区有人在讨论视频网站应用和Swift的结合，窃以为是值得关注的方向。
Glance
Glance比较简单，是一个虚机镜像的存储。向前端nova（或者是安装了Glance-client的其他虚拟管理平台）提供镜像服务，包括存储，查询和检索。这个模块本身不存储大量的数据，需要挂载后台存储（Swift，S3。。。）来存放实际的镜像数据。
Glance主要包括下面几个部分：
l API service： glance-api 主要是用来接受Nova的各种api调用请求，将请求放入RBMQ交由后台处理，。
l Glacne-registry 用来和MySQL数据库进行交互，存储或者获取镜像的元数据，注意，刚才在Swift中提到，Swift在自己的Storage Server中是不保存元数据的，这儿的元数据是指保存在MySQL数据库中的关于镜像的一些信息，这个元数据是属于Glance的。
l Image store： 后台存储接口，通过它获取镜像，后台挂载的默认存储是Swift，但同时也支持Amazon S3等其他的镜像。
Glance从某种角度上看起来有点像虚拟存储，也提供API，可以实现比较完整的镜像管理功能。所以理论上其他云平台也可以使用它。
Glance比较简单，又限于云内部，所以没啥可以多展开讨论的，不如看看新出来的块存储组件Cinder，目前我对Cinder基本的看法是总体的设计不错，细节和功能还有很多需要完善的地方，离一个成熟的产品还有点距离。
Cinder
OpenStack到F版本有比较大的改变，其中之一就是将之前在Nova中的部分持久性块存储功能（Nova-Volume）分离了出来，独立为新的组件Cinder。它通过整合后端多种存储，用API接口为外界提供块存储服务，主要核心是对卷的管理，允许对卷，卷的类型，卷的快照进行处理。
Cinder包含以下三个主要组成部分
API service：Cinder-api 是主要服务接口, 负责接受和处理外界的API请求，并将请求放入RabbitMQ队列，交由后端执行。 Cinder目前提供Volume API V2
Scheler service: 处理任务队列的任务，并根据预定策略选择合适的Volume Service节点来执行任务。目前版本的cinder仅仅提供了一个Simple Scheler, 该调度器选择卷数量最少的一个活跃节点来创建卷。
Volume service: 该服务运行在存储节点上，管理存储空间，塔处理cinder数据库的维护状态的读写请求，通过消息队列和直接在块存储设备或软件上与其他进程交互。每个存储节点都有一个Volume Service，若干个这样的存储节点联合起来可以构成一个存储资源池。
Cinder通过添加不同厂商的指定drivers来为了支持不同类型和型号的存储。目前能支持的商业存储设备有EMC 和IBM的几款，也能通过LVM支持本地存储和NFS协议支持NAS存储，所以Netapp的NAS应该也没问题，好像华为也在努力中。我前段时间还在Cinder的blueprints看到IBM的GPFS分布式文件系统，在以后的版本应该会添加进来
到目前为止，Cinder主要和Openstack的Nova内部交互，为之提供虚机实例所需要的卷Attach上去，但是理论上也可以单独向外界提供块存储。
部署上，可以把三个服务部署在一台服务器，也可以独立部署到不同物理节点
现在Cinder还是不够成熟，有几个明显的问题还没很好解决，一是支持的商业存储还不够多，而且还不支持FC SAN，另外单点故障隐患没解决，内部的schele调度算法也太简单。另外由于它把各种存储整合进来又加了一层，管理倒是有办法了，但是效率肯定是有影响，性能肯定有损耗，但这也是没办法的事了。
Openstack通过两年多发展，变得越来越庞大。目前光存储就出现了三种：对象存储、镜像存储和块存储。这也是为了满足更多不同的需求，体现出开源项目灵活快速的特性。总的说来，当选择一套存储系统的时候，如果考虑到将来会被多个应用所共同使用，应该视为长期的决策。Openstack作为一个开放的系统，最主要是解决软硬件供应商锁定的问题，可以随时选择新的硬件供应商，将新的硬件和已有的硬件组成混合的集群，统一管理，当然也可以替换软件技术服务的提供商，不用动应用。这是开源本身的优势！
㈣ 公有云的云存储好在哪里
公有云的云存储，现在一般都是网盘服务，有私人的有企业的。云存储的最大特点是扩容方便，因为云具有可扩展性。公有云云存储的特点主要是维护不用自己管，大服务商的安全性比自建系统要高很多，速度快，更新快，功能全，随处都可以访问，任何终端都可以访问，还有很多接口供开发利用。目前私人网盘管理的比较严，一般不能发外链，共享是个问题。企业网盘功能比较全，联想、搜狐、开普云都有，费用也不算高，好像开普云还有免费的服务。
㈤ 公有云与私有云的区别
“公有云”和“私有云”其本质都是一种能提供更好服务的存储架构技术，但他们却有着明显的差别，最显着差别在于对数据的掌控。接下来优炫软件带你看看这两朵“云”都有那些区别。
在正式开讲前，我们先来了解一下“公有云”和“私有云”的定义：
1、公有云（PublicClouds）：
“公有”反映了这类云服务并非用户所拥有，公有云是面向大众提供计算资源的服务。是由IDC服务商或第三方提供资源，如应用和存储，这些资源是在服务商的场所内部署。用户通过Internet互联网来获取这些资源的使用。公有云服务提供商有Amazon、Google和微软，以及国内的阿里云、腾讯云、百悟云等。
公有云的优势是成本低，扩展性非常好。缺点是对于云端的资源缺乏控制、保密数据的安全性、网络性能和匹配性问题。
2、私有云（PrivateClouds）：
私有云是企业传统数据中心的延伸和优化，能够针对各种功能提供存储容量和处理能力。“私有”更多是指此类平台属于非共享资源，而非指其安全优势。私有云是为了一个客户单独使用而构建的，所以这些数据、安全和服务质量都较公有云有着更好地保障。而私有云由于是客户独享，则用户拥有着构建云的基础设置，并可以控制在此技术设置上部署应有程序的方式。
在私有云模式中，云平台的资源为包含多个用户的单一组织专用。私有云可由该组织、第三方或两者联合拥有、管理和运营。私有云的部署场所可以是在机构内部，也可以在外部。
通过定义我们可以看出，私有云构筑一个公司企业数据中心内的专用云。而公有云则是针对外部客户，通过网络方式提供可扩展的弹性服务。在选择公有云还是私有云时，根据用户自身的需求各有偏重。
除了应用场景， “安全”是首要关心的问题，因为对于任何的业务来说安全无疑是最基本的要求。毕竟大数据时代，企业信息就是企业的生命。
采用公有云办公的企业必需将数据托管于云办事商的数据中心，企业对数据的掌控力度自然减弱。一旦数据中心因自然灾害、报答因素或法律规范等各方面因素导致数据丢失，将对企业或政府机构形成致命伤害。
私有云在数据安全、数据备份等方面具有更多的可选择空间。公有云当然也具备数据安全办事和数据备份能力，但企业对此的控制力度较差，不处于主导地位。
㈥ MicroFocus的Data Protector支持阿里云和腾讯云的对象存储吗
MicroFocus的Data Protector支持国内公有云的S3接口的对象存储。
㈦ 新一代私有云是什么私有云有什么价值与意义
私有云是什么？
参照维基网络定义：
私有云（Private cloud）是将云基础设施与软硬件资源建立在防火墙内，以供机构或企业内各部门共享数据中心内的资源。私有云完全为特定组织而运作的云端基础设施，管理者可能是组织本身，也可能是第三方；位置可能在组织内部，也可能在组织外部。
3大私有云主流落地方案，超融合正成为构建新一代私有云“基石”的主流方案
目前主流企业级私有云落地方案主要有以下三种，下面逐一介绍，并讲解其各自特点：
将AWS、Azure、阿里云等商业公有云方案全套落地到私有环境；
使用类似 OpenStack、Ceph 等开源软件构建私有云；
使用类似 VMware、SmartX、Nutanix 等虚拟化或超融合产品配合 CMP 组件等成熟的商业组件构建私有云。
一个有趣的现象是，由于 HCI 架构为私有云带来的诸多优势，方式 1、2 也都衍生了基于超融合架构的落地方案，超融合正成为构建新一代私有云“基石”的主流方案。以下逐一介绍。
公有云移植构建私有云
将公有云移植到企业数据中心，方案最大的优势是它来自于公有云成功经验，并经过长时间，大规模营运的考验，拥有比较全面的功能，以 AWS 为例展示其落地方案及架构。
在资源池的构建上方式上，以往 VMware vSpere 、FC 网络、FC SAN 存储传统三层式架构占据统治地位，但超融合方案正在越来越多地替换原有的架构。VMware、SmartX、等主流超融合厂商配合成熟的商用 CMP 产品都提供了诸多基于超融合架构的私有云案例。相比于以上两种方案，该落地方案具有独特的特点：
1.相比于公有云厂商以及全栈的私有云方案，该方案具备更好的开放性，更灵活轻量；
2. 相比于基于的开源产品，该方案稳定简单，具备真正“生产就绪“能力。
私有云有什么价值与要求？
公有云用户只需关注资源使用和付费，私有云不仅要求资源交付上需具备可扩展、弹性的能力，更大的挑战还来自于：整体方案从规划、部署到交付、运维各个环节都需要符合以下核心要求：
按需投资：可以根据业务实际需要进行不同层面以及不同规模的按需投资。例如 IaaS 层和 PaaS 层的分阶段构建，IaaS 层中管理平台和资源池的分别构建，以及资源池根据业务情况的逐步扩容；
快速上线：私有云不仅要求资源的快速交付，还要求支持业务系统的自动部署及便捷的线上扩容；
运维简单：私有云场景下，企业既是使用方同时也是营运方，运维人员是非常有限的。因此，私有云的运维应尽可能简单，同时保证系统复杂性不随系统规模扩大而大幅增加。这样可以避免复杂的运维成为业务快速增长的瓶颈，以及对系统的稳定性带来隐患；
生产就绪：当用户进行私有云化改造的时候，通常只关注了功能特性，而忽略了私有云最终是要承载生产业务，才能真正实现的企业数据中心“云化”转型目标。因此，方案乃至供应商服务的“生产就绪“能力可以保障架构转型可持续、深入地进行，而不是仅停留在实验阶段；
成本合理：所有的转型最终都需要以经济效益衡量。私有云方案不仅需要关注采购成本，还要关注使用成本、维护成本以及软硬件维保和升级等各方面成本。
㈧ 企业网盘公有云，私有云和混合云的区别
区别在于网盘部署位置。
私有云是在企业自己的服务器内部署网盘，公有云是第三方服务器内，混合云就是公有和私有云的混合体，目前云网盘计算很成熟。