1.公有云和私有云

1.1.公有云定义

公有云通常指第三方提供商为用户提供的能够使用的云，公有云一般可通过 Internet 使用，可能是免费或成本低廉的，公有云的核心属性是共享资源服务。这种云有许多实例，可在当今整个开放的公有网络中提供服务，比如我们经常使用阿里云即是一种公有云。

公有云被认为是云计算的主要形态，目前市场上公有云也是占据了较大的市场份额的，在国内公有云可以分为以下几类：

1、传统的电信基础设施运营商，比如中国移动、中国联通中国电信等提供的公有云服务。

2、一类是主导的地方性云计算平台，也就是常说的云。

3、互联网巨头打造的公有云平台，比如阿里云、腾讯云、华为云等等。

4、部分IDC运营商，比如世纪互联。

5、还有部分国外的云计算企业，比如亚马逊、AWS、GOOGLE等。

1.2.私有云定义

    私有云(Private Clouds)是为一个客户单独使用而构建的，因而提供对数据、安全性和服务质量的最有效控制。私有云的基础是首先你要拥有基础设施并可以控制在此基础设施上部署应用程序的方式。私有云可以部署在企业数据中心的防火墙内，也可以将它们部署在一个安全的主机托管场所，私有云的核心属性是专有资源。

    私有云可以搭建在公司的局域网上，与公司内部的公司的监控系统、资产管理系统等相关系统进行打通，从而更有利于公司内部系统的集成管理。  

    私有云虽然数据安全性方面比公有云高，但是维护的成本也相对较大（对于中小企业而言），因此一般只有大型的企业会采用这类的云平台，因为对于这些企业而言，业务数据这条生命线不能被任何其他的市场主体获取到，与此同时，一个企业尤其是互联网企业发展到一定程度之后，自身的运维人员以及基础设施都已经比较充足完善了，搭建自己的私有云有时候成本反而会比公有云来得低（所谓的规模经济）。举个例子：百度绝对不会使用阿里云，不仅是出于自己的数据安全方面的考虑，成本也是一个比较大的影响因素。

1.3.公有云和私有云区别

   从以下几个方面进行比较。

用户：私有云针对和大型企业；公有云针对创业公司和个人。

业务场景：私有云政企内部业务；公有云对外互联网业务。

技术架构：私有云OpenStack开源架构关注高可用、灵活性；公有云自研架构、关注分布式、大集群。

兼容性：私有云主动兼容和适配自身业务；公有云根据公有云要求来修改自身业务达到适配。

安全：私有云网络层实现安全隔离；公有云主机层实现安全隔离。

定制：私有云灵活定制与现有系统进行集成；公有云非特殊不能定制。

成本：私有云初期成本高随之业务量增加后期成本低；公有云初期成本低后期业务量大时成本高。

运维：私有云自主运维也可托管给第三方运维；公有云用户无法自主运维由公有云服务商统一运维。

    但是随着技术的发展与创新，混合云成为了近年来云计算的主要模式和发展方向。混合云融合了公有云和私有云，我们已经知道私企业主要是面向企业用户，出于安全考虑，企业更愿意将数据存放在私有云中，但是同时又希望可以获得公有云的计算资源，在这种情况下混合云被越来越多的采用，它将公有云和私有云进行混合和匹配，以获得最佳的效果，这种个性化的解决方案，达到了既省钱又安全的目的，从而获得越来越多企业的青睐。

2.“云”的组成部分及其作用

云是一种为提供自助服务而开发的虚拟环境。云就是网络，由于网络拓扑结构的多样性，所以通常画成云。一个大型的网络平台就是云平台。

云，作为未来的发展趋势，其核心是：当你的计算机作为端口接入云端（接入网络），云内的资源全部为云端服务，计算机只作为窗口，而运算、处理、客户端全部放在网络服务器（云平台）上。

如果把云比喻成一个公司的话，那么云计算就是公司的规章制度、云服务就是公司各个部门，而云主机就是公司某部门的一个职员。

所以云是由云计算、云服务、云主机这三个框架构成。

3

4

2.1.云计算

云计算（Cloud Computing）是分布式计算（Distributed Computing）、并行计算（Parallel Computing）、效用计算（Utility Computing）、网络存储（Network Storage Technologies）、虚拟化（Virtualization）、负载均衡（Load Balance）、热备份冗余（High Available）等传统计算机和网络技术发展融合的产物。是基于互联网的相关服务的增加、使用和交付模式，通常涉及通过互联网来提供动态易扩展且经常是虚拟化的资源。是一种计算方法，它可以将按需提供的自助服务汇聚成高效池，以服务的形式交付使用。就像你平时使用的自动售货机，你输入你的需求，就能够得到你想要的，而不需要通过其它任何部门及个人去协调处理，这将极大的提高工作效率。

云计算特点如下：

超大规模

   “云”具有相当的规模，Google云计算已经拥有100多万台服务器， Amazon、IBM、微软、Yahoo等的“云”均拥有几十万台服务器。企业私有云一般拥有数百上千台服务器。“云”能赋予用户前所未有的计算能力。

虚拟化

    云计算支持用户在任意位置、使用各种终端获取应用服务。所请求的资源来自“云”，而不是固定的有形的实体。应用在“云”中某处运行，但实际上用户无需了解、也不用担心应用运行的具体位置。只需要一台笔记本或者一个手机，就可以通过网络服务来实现我们需要的一切，甚至包括超级计算这样的任务。

高可靠性

   “云”使用了数据多副本容错、计算节点同构可互换等措施来保障服务的高可靠性，使用云计算比使用本地计算机可靠。方法却无法

通用性

    云计算不针对特定的应用，在“云”的支撑下可以构造出千变万化的应用，同一个“云”可以同时支撑不同的应用运行。却无法却无法

高可扩展性

   “云”的规模可以动态伸缩，满足应用和用户规模增长的需要。欺负

按需服务

   “云”是一个庞大的资源池，你按需购买；云可以像自来水，电，煤气那样计费。

极其廉价

    由于“云”的特殊容错措施可以采用极其廉价的节点来构成云，“云”的自动化集中式管理使大量企业无需负担日益高昂的数据中心管理成本，“云”的通用性使资源的利用率较之传统系统大幅提升，因此用户可以充分享受“云”的低成本优势，经常只要花费几百美元、几天时间就能完成以前需要数万美元、数月时间才能完成的任务。云计算可以彻底改变人们未来的生活，但同时也要重视环境问题，这样才能真正为人类进步做贡献,而不是简单的技术提升。

2.2 云服务

云服务是基于互联网的相关服务的增加、使用和交付模式，通常涉及通过互联网来提供动态易扩展且经常是虚拟化的资源。云提供有三种层面的服务：基础架构即服务、平台即服务、软件即服务。未来将会出现各种各样的云产品。通常所说的云服务，其实就是指云三种层次的服务中的一种。

云服务特点如下：

通过使计算分布在大量的分布式计算机上，而非本地计算机或远程服务器中，企业数据中心的运行将与互联网更相似。这使得企业能够将资源切换到需要的应用上，根据需求访问计算机和存储系统。

好比是从古老的单台发电机模式转向了电厂集中供电的模式。它意味着计算能力也可以作为一种商品进行流通，就像煤气、水电一样，取用方便，费用低廉。最大的不同在于，它是通过互联网进行传输的。

2.3 云主机

云主机是云计算在基础设施应用上的重要组成部分，位于云计算产业链金字塔底层。云主机是在一组集群主机上虚拟出多个类似主机的部分，集群中每个主机上都有云主机的一个镜像，从而大大提高了虚拟主机的安全稳定性，除非所有的集群内主机全部出现问题，云主机才会无法访问。

    云主机特点如下：

更优价格：品牌服务器、零首付、零押金、零维护，按月支付按月使用，同等性能价格更低。

高可靠性：主机服务支持多级的备份与恢复，包括备机、系统备份与应用备份。

安全性：从硬件级别上实现故障和安全性的隔离，平台内置ARP攻击防护能力，分布式和规模化提升防DDOS攻击能力。

自助服务：通过基于浏览器的自服务界面，客户可远程安装操作系统，远程集中管理分布在不同数据中心的云服务器，省心省力。

高性能：主机业务单元，独占硬件资源，提供独享带宽，确保高性能。

快速供应：提供多种操作系统和应用标准镜像，需求无论是一台还是百台、Windows还是Linux，均可实现瞬时供应和部署。

SLA：基于IBM Tivilo和NetCool的监控和故障报警平台，24*7的专业运维服务团队，提供最高等级的SLA。

弹性计算平台：用户对配置需求发生变化时，无需任何对系统、环境和数据做任何变更，即可实现主机配置的快速扩容。

多节点可选：云计算节点覆盖全国多个城市的电信、网通、BGP线路，各种接入方式用户可自主选择。

买一台云主机=拥有海量服务器!千兆光纤、骨干节点、BGP智能多线机房，智能免费备份，数据随时恢复，按需购买，平滑升级，无需停机 ，免费提供正版系统！云主机比主机更便宜 ,比VPS更强更稳, 管理易如虚拟主机！

3Openstack云架构技术

1.

2.

3.

5

2.2

2.

3.

3.1.Openstack是什么

OpenStack是一个由NASA（美国国家航空航天局）和Rackspace合作研发并发起的，以Apache许可证授权的自由软件和开放源代码项目。

OpenStack提供开放源码软件，建立公共和私有云。 OpenStack是一个社区和一个项目，以及开放源码软件，以帮助企业运行的虚拟计算或者存储云。 OpenStackd开源项目由社区维护，包括OpenStack计算（代号为Nova），OpenStack对象存储（代号为SWIFT），并OpenStack镜像服务（代号Glance）的集合。 OpenStack提供了一个操作平台，或工具包，用于编排云。

    OpenStack当前主要有三个组件：计算，存储，镜像。

    OpenStack计算是一个云控制器，用来启动一个用户或一个组的虚拟实例它也用于配置每个实例或项目中包含多个实例为某个特定项目的联网。

OpenStack对象存储是一个在具有内置冗余和容错的大容量系统中存储对象的系统。对象存储有各种应用，如备份或存档数据，存储图形或视频（流媒体数据传输到用户的浏览器），储存二级或三级静态数据，发展与数据存储集成新的应用程序，当预测存储容量困难时存储数据，创造弹性和灵活的云存储Web应用程序。

OpenStack镜像服务是一个查找和虚拟机图像检索系统。它可以配置三种方式：使用OpenStack对象存储来存储图像;使用亚马逊S3直接存储，或使用S3对象存储作为S3访问中间存储。

三者关系如下图：

3.2.云服务提供商的概念架构

OpenStack能帮我们建立自己的IaaS，提供类似AmazonWebService的服务给客户。为实现这一点，我们需要提供几个高级特性：

a)允许应用拥有者注册云服务，查看运用和计费情况;

b)允许Developers/DevOpsfolks创建和存储他们应用的自定义镜像;

c)允许他们启动、监控和终止实例;

d)允许CloudOperator配置和操作基础架构

这四点都直击提供IaaS的核心，现在假设你同意了这四个特性，现在就可以将它们放进如下所示的概念架构中。

OpenStack 概念架构

在此模型中，作者假设了需要与云交互的四个用户集：developers,devops,ownersandoperators，并为每类用户划分了他们所需要的功能。该架构采用的是非常普通的分层方法(presentation,logicandresources)，它带有两个正交区域。

展示层，组件与用户交互，接受和呈现信息。Webportals为非开发者提供图形界面，为开发者提供API端点。如果是更复杂的结构，负载均衡，控制代理，安全和名称服务也都会在这层。

逻辑层为云提供逻辑(intelligence)和控制功能。这层包括部署(复杂任务的工作流)，调度(作业到资源的映射)，策略(配额等等)，镜像注册imageregistry(实例镜像的元数据)，日志(事件和计量)。

假设绝大多数服务提供者已经有客户身份和计费系统。任何云架构都需要整合这些系统。

在任何复杂的环境下，我们都将需要一个management层来操作这个环境。它应该包括一个API访问云管理特性以及一些监控形式(forms)。很可能，监控功能将以整合的形式加入一个已存在的工具中。当前的架构中已经为我们虚拟的服务提供商加入了monitoring和adminAPI，在更完全的架构中，你将见到一系列的支持功能，比如provisioning和configurationmanagement。

最后，资源层。既然这是一个compute云，我们就需要实际的compute、network和storage资源，以供应给我们的客户。该层提供这些服务，无论他们是服务器，网络交换机，NAS(networkattachedstorage)还是其他的一些资源。

3.3.OpenStack Compute逻辑架构

OpenStack Compute逻辑架构中，组件中的绝大多数可分为两种自定义编写的Python守护进程(custom written python daemons)。

a) 接收和协调API调用的WSGI应用(nova-api, glance-api, etc)

b) 执行部署任务的Worker守护进程(nova-compute, nova-network, nova-schedule, etc.)

然而，逻辑架构中有两个重要的部分，既不是自定义编写，也不是基于Python，它们是消息队列和数据库。二者简化了复杂任务(通过消息传递和信息共享的任务)的异步部署。

逻辑架构图如下所示：

从图中，我们可以总结出三点：

a) 终端用户(DevOps, Developers 和其他的 OpenStack 组件)通过和nova-api对话来与OpenStack Compute交互。

b) OpenStack Compute守护进程之间通过队列(行为)和数据库(信息)来交换信息，以执行API请求。

c) OpenStack Glance基本上是的基础架构，OpenStack Compute通过Glance API来和它交互。

其各个组件的情况如下：

a) nova-api守护进程是OpenStack Compute的中心。它为所有API查询(OpenStack API 或 EC2 API)提供端点，初始化绝大多数部署活动(比如运行实例)，以及实施一些策略(绝大多数的配额检查)。

b) nova-compute进程主要是一个创建和终止虚拟机实例的Worker守护进程。其过程相当复杂，但是基本原理很简单：从队列中接收行为，然后在更新数据库的状态时，执行一系列的系统命令执行他们。

c) nova-volume管理映射到计算机实例的卷的创建、附加和取消。这些卷可以来自很多提供商，比如，ISCSI和AoE。

d) Nova-network worker守护进程类似于nova-compute和nova-volume。它从队列中接收网络任务，然后执行任务以操控网络，比如创建bridging interfaces或改变iptables rules。

e) Queue提供中心hub，为守护进程传递消息。当前用RabbitMQ实现。但是理论上能是python ampqlib支持的任何AMPQ消息队列。

f) SQL database存储云基础架构中的绝大多数编译时和运行时状态。这包括了可用的实例类型，在用的实例，可用的网络和项目。理论上，OpenStack Compute能支持SQL-Alchemy支持的任何数据库，但是当前广泛使用的数据库是sqlite3(仅适合测试和开发工作)，MySQL和PostgreSQL。

g) OpenStack Glance，是一个单独的项目，它是一个compute架构中可选的部分，分为三个部分：glance-api, glance-registry and the image store. 其中，glance-api接受API调用，glance-registry负责存储和检索镜像的元数据，实际的Image Blob存储在Image Store中。Image Store可以是多种不同的Object Store，包括OpenStack Object Storage (Swift)

h) 最后，user dashboard是另一个可选的项目。OpenStack Dashboard提供了一个OpenStack Compute界面来给应用开发者和devops staff类似API的功能。当前它是作为Django web Application来实现的。当然，也有其他可用的Web前端。

3.4.概念映射

将逻辑架构映射到概念架构中(如下图所示)，可以看见我们还缺少什么。

这种覆盖方式并不是唯一的，这里的只是作者的理解。通过覆盖OpenStack Compute 逻辑组件，Glance和Dashboard，来表示功能范围。对于每一个覆盖，都有相应的提供该功能的逻辑组件的名称。

a) 在这种覆盖范围中，最大的差距是logging和billing。此刻，OpenStack Compute没有能协调logging事件、记录日志以及创建/呈现bills的Billing组件。真正的焦点是logging和Billing的整合。这能通过以下方式来补救。比如代码扩充，商业产品或者服务或者自定义日志解析的整合。

b) Identity也是未来可能要补充的一点。

c) customer portal也是一个整合点。user dashboard(见运行的实例，启动新的实例)没有提供一个界面，来允许应用拥有者签署服务，跟踪它们的费用以及声明有问题的票据(lodge trouble tickets)。而且，这很可能对我们设想的服务提供商来说是合适的。

d) 理想的情况是，Admin API会复制我们能通过命令行接口做的所有功能。在带有Admin API work的Diablo 发布中会更好。

e) 云监控和操作将是服务提供商关注的重点。好操作方法的关键是好的工具。当前，OpenStack Compute 提供 nova-instancemonitor，它跟踪计算结点使用情况。未来我们还需要三方工具来监控。

f) Policy是极其重要的方面，但是会与供应商很相关。从quotas到QoS，到隐私控制都在其管辖内。当前图上有部分覆盖，但是这取决于供应商的复杂需求。为准确起见，OpenStack Compute 为实例，浮点IP地址以及元数据提供配额。

g) 当前，OpenStack Compute内的Scheduling对于大的安装来说是相当初步的。调度器是以插件的方式设计的，目前支持chance(随机主机分配)，simple(最少负载)和zone(在一个可用区域里的随机结点。)分布式的调度器和理解异构主机的调度器正在开发之中。

如你所见，OpenStack Compute为我们想象的服务提供商，提供了一个不错的基础，只要服务提供商愿意做一些整合。

3.5  OpenStack Compute系统架构

OpenStack Compute由一些主要组件组成。“Cloud controller”包含很多组件，它表示全局状态，以及与其他组件交互。实际上，它提供的是Nova-api服务。它的功能是：为所有API查询提供一个端点，初始化绝大多数的部署活动，以及实施一些策略。API 服务器起cloud controller web Service前端的作用。Compute controller 提供compute服务资源，典型包含compute service，Object Store component可选地提供存储服务。Auth manager提供认证和授权服务，Volume controller为compute servers提供快速和持久的块级别存储。Network controller提供虚拟网络使compute servers彼此交互以及与公网进行交互。Scheduler选择最合适的compute controller来管理(host)一个实例。

OpenStack Compute建立在无共享、基于消息的架构上。Cloud controller通过HTTP与internal object store交互，通过AMQP和scheduler、network controller、 和volume controller 来进行通信。为了避免在等待接收时阻塞每个组件，OpenStack Compute用异步调用的方式。

为了获得带有一个组件多个备份的无共享属性，OpenStack Compute将所有的云系统状态保持在分布式的数据存储中。对系统状态的更新会写到这个存储中，必要时用质子事务。

对系统状态的请求会从store中读出。在少数情况下，控制器也会短时间缓存读取结果。

3.6  OpenStack Compute物理架构

OpenStack Compute采用无共享、基于消息的架构，非常灵活，我们能安装每个nova- service在单独的服务器上，这意味着安装OpenStack Compute有多种可能的方法。可能多结点部署唯一的联合依赖性，是Dashboard必须被安装在nova-api服务器。几种部署架构如下：

a) 单结点：一台服务器运行所有的nova- services，同时也驱动虚拟实例。这种配置只为尝试OpenStack Compute，或者为了开发目的;

b) 双结点：一个cloud controller 结点运行除nova-compute外的所有nova-services，compute结点运行nova-compute。一台客户计算机很可能需要打包镜像，以及和服务器进行交互，但是并不是必要的。这种配置主要用于概念和开发环境的证明。

c) 多结点：通过简单部署nova-compute在一台额外的服务器以及拷贝nova.conf文件到这个新增的结点，你能在两结点的基础上，添加更多的compute结点，形成多结点部署。在较为复杂的多结点部署中，还能增加一个volume controller 和一个network controller作为额外的结点。对于运行多个需要大量处理能力的虚拟机实例，至少是4个结点是最好的。

一个可能的Openstack Compute多服务器部署(集群中联网的虚拟服务器可能会改变)如下图所示：

如果你注意到消息队列中大量的复制引发了性能问题，一种可选的架构是增加更多的Messaging服务器。在这种情形下，除了可以扩展数据库服务器外，还可以增加一台额外的RabbitMQ服务器。部署中可以在任意服务器上运行任意nova-service，只要nova.conf中配置为指向RabbitMQ服务器，并且这些服务器能发送消息到它。

下图是另外一种多结点的部署架构。

3.7  OpenStack Compute服务架构

因为Compute有多个服务，也可能有多种配置，下图显示了总体的服务架构，以及服务之间的通信系统。

4.

5.

5.1.

5.1.1.

5.1.2.

5.1.3.

5.1.4.

5.1.5.

5.1.6.

5.1.7.

3.8  OpenStack的特点

    OpenStack 是一套框架 —— API，它有两个特点：

　　它是一个中间层，可以创建、管理和销毁虚拟机，但是要完成这些操作需要依赖于第三方的 Hypervisor，通过这个 Hypervisor 去完成虚拟化的工作，OpenStack 并不能自己去提供一个虚拟化的运行环境，OpenStack 有个组件叫 Cinder（用来提供块存储服务的），但是 OpenStack 自己并不能进行数据的存储和读写，它需要依赖一个实际的块存储设备的支持，这个设备可以是一个分布式的存储系统，比如说 Ceph，也可以是一个存储设备，比如说 EMC 的 SAN，也可以是存储服务器的本地硬盘，但是它必须依赖一个存储设备的支持，OpenStack 本身并不具备这个功能。OpenStack 是一个中间层。

　　框架有一个很重要的特点，那就是它能提供一批 API 去支持应用的开发，这也是我们业内对框架的一个定义，OpenStack 当然也有这个特点，云计算的愿景就是让用户能够像用电一样去使用计算，OpenStack 的设计也是朝着这个愿景去做设计的，但是实际上我们平时是不能直接用电的，我们需要用的是电冰箱、电脑、电视等等这些电器。同理，对于云计算来说，提供 API 去支持开发应用这个事情就合情合理的非常的重要了，具有完备的 API 是 OpenStack 的突出优点。

4Vmware云架构技术

3.

4.

4.1VMware是什么

VMware（中文名威睿”，纽约证券交易所“代码：VMW） 虚拟机软件，是全球桌面到数据中心虚拟化解决方案的领导厂商。VMware（纽约证交所代码：VMW）在虚拟化和云计算基础架构领域处于全球领先地位，所提供的经客户验证的解决方案可通过降低复杂性以及更灵活、敏捷地交付服务来提高IT效率。VMware使企业可以采用能够解决其独有业务难题的云计算模式。VMware提供的方法可在保留现有投资并提高安全性和控制力的同时，加快向云计算的过度。

    VMware最著名的产品为ESX，安装在裸服务器上的强大server，系列产品升级，更名为vSphere系列，最新产品为vSphere 5.5。是VMware的企业级产品，该产品一直遥遥领先于微软Hyper-V跟思杰Xen。是构建大企业数据中心的不二之选，中国很大一部分商业银行，保险公司，电信公司以及部门都在使用。其架构也是云计算的底层。

VMware view是桌面产品，企业级产品。

其次，VMware第二大产品为：VMware Workstation虚拟机是一个在Windows或Linux计算机上运行的应用程序，它可以模拟一个基于x86的标准PC环境。这个环境和真实的计算机一样，都有芯片组、CPU、内存、显卡、声卡、网卡、软驱、硬盘、光驱、串口、并口、USB控制器、SCSI控制器等设备，提供这个应 用程序的窗口就是虚拟机的显示器。

在使用上，这台虚拟机和真正的物理主机没有太大的区别，都需要分区、格式化、安装操作系统、安装应用程序和软件，总之，一切操作都跟一台真正的计算机一样。

4.2. VmwareVDI桌面虚拟化架构

4.2.1工作原理

VMware VDI易于管理，它集成了VMware Infrastructure 3和VMware Virtual Desktop Manager 2，通过管理在数据中心上运行的多个PC系统，并进行安全灵活的分发给客户端使用。首先，用户使用Vmware VDI需要以下几个步骤：

1、 在ESX服务器上创建一个虚拟机

2、 安装VDI 代理连接

　　3、 在虚拟机上安装一个桌面操作系统，如Windows XP或Windows Vista

　　4、 接着在虚拟机上安装桌面应用系统

　　5、 允许通过网络使用任何一些可能的远程控制选项去远程访问的虚拟桌面系统

　　典型的Vmware VDI环境都包括以下几个组件：VMware Infrastructure 3、VMware Virtual Desktop Manager、客户端。此外，要运行 VMware Virtual Desktop Manager 软件，还需要有 Microsoft Active Directory。

　　运行Vmware VDI的同时，可以使用VMware Virtual Desktop Manager (VDM)，它是一种企业级桌面管理服务器，可安全地将用户连接到数据中心的虚拟桌面，并提供易于使用的基于Web 的界面来管理集中的环境。企业可以在位于数据中心的虚拟机内部运行桌面。使用 VMware Virtual Desktop Manager 连接代理，用户可通过远程显示协议(如 RDP)从 PC 或瘦客户端远程访问这些桌面。如图显示Vmware VDI环境结构图：

使用Vmware VDI 既可以对企业资产进行严格的控制又可以简化桌面管理。这一综合性的桌面虚拟化解决方案可以使用户通过数据中心对虚拟机进行管理，从而取代传统的PC机。

4.2.2Vmware VDI优点

Vmware VDI在其官网上称：可提供支持远程和分支机构的用户可以访问设在数据中心的虚拟台式机，并可以提高远程工作者和在家工作者的桌面安全。通过将数据中心的桌面集中在一起，企业便可从提高的管理和控制能力中获益。最终用户从任何位置均可访问其熟悉的企业桌面，这种功能可以使单个最终用户从中获益。

　　也就是说，企业桌面虚拟化在以往基础上更进一步，除去了桌面上的计算机，取而代之的是超小型、完全安全的智能网络应用终端，它们连接到各自位于数据中心的虚拟桌面。通过整合到数据中心中的桌面环境，企业可以提供始终可用的安全、的桌面。从网络上的任何位置都可以集中管理和访问每台智能网络应用终端。从而使 IT 部门可以：

　　1、减少个人计算机维护成本

　　2、提高安全性

　　3、在服务器上部署完整的个人计算机桌面

　　4、几分钟内就可以设置工作组和整个部门

　　VDI 是一种基于服务器的计算技术，但是与终端服务或共享应用程序解决方案相比，它能提供一些令人信服的优势：

　　1、 与应用程序共享技术不同的是，在集中式服务器上运行的 VMware VDI 桌面是完全的，这有助于阻止对桌面映像进行未经授权的访问，并同时提高可靠性。

　　2、 使用虚拟机模板和自动部署功能可以轻松地部署 VMware 桌面。而且无需更改应用程序，因为用户只需通过远程连接即可访问同一桌面。

　 3、 公司可以利用 VMware Infrastructure 3 组件(如 VMware Consolidated Backup)和共享存储来提供终端服务解决方案目前无法提供的桌面灾难恢复功能。

　　4、 VMware VDI 仍享有基于服务器的计算技术所能带来的一些引人注目的好处，包括简化桌面管理以及能够从位置升级和修补系统。

　　VMware VDI 还避免了大多数刀片 PC 技术(另一种基于服务器的计算技术)的一些缺点。未利用 VMware 虚拟化技术的刀片 PC 需要每一个桌面有一个专用的刀片 PC，而这需要大量的成本。使用 VMware VDI，公司可以实现桌面虚拟化技术在整合和效率方面所能带来的相同好处，同时仍可以为最终用户提供可自定义的个人桌面。

4

4.2

4.3 服务器虚拟化

服务器虚拟化技术是指能够在一台物理服务器上运行多台虚拟服务器的技术，并且上述虚拟服务器在用户、应用软件甚至操作系统看来，几乎与物理服务器没有区别，用户可以在虚拟服务器上灵活地安装任何软件。除此以外，服务器虚拟化技术还应该确保上述多个虚拟服务器之间的数据是隔离的，虚拟服务器对资源的占用是可控的。

　　在服务器虚拟化技术中，被虚拟出来的服务器称为虚拟机（Virtual Machine，VM）。运行在虚拟机里的操作系统称为客户操作系统，即Guest OS。负责管理虚拟机的软件称为虚拟机管理器，缩写为VMM，也称为Hypervisor。

服务器虚拟化通常有两种架构，分别是寄生架构（Hosted）与裸金属架构（Bare-metal）。

寄生架构

一般而言，在使用计算机之前，首先要安装操作系统，该操作系统称为宿主操作系统，即Host OS。如果采用虚拟机技术，则需要在操作系统之上再安装一个VMM，然后利用这个VMM创建并管理虚拟机。这种后装模式称为寄生架构，因为VMM看起来像是“寄生”在操作系统上的。例如，Oracle公司的VirtualBox就是一种寄生架构。

裸金属架构。

顾名思义，裸金属架构是指将VMM直接安装在物理服务器之上而无须先安装操作系统的预装模式。在安装了VMM之后，再在VMM上安装其他操作系统（如Windows、Linux等）。由于VMM“看起来”是直接安装在物理计算机上的，所以称为裸金属架构，例如KVM、Xen、VMware ESX。

目前，普遍认为裸金属架构的性能要比寄生架构高。很多资料都宣传说，裸金属架构是直接运行在物理硬件之上的，无须通过Host OS，所以性能更高。

图1为Xen的工作流程，其中有3个Domain。一开始，很多人会将Domain误认为是CPU的一种特殊状态，这是因为在很多文档里会用一些比较模糊的措辞，例如“此时，系统会进入Domain 0状态”，从而让人产生误解。其实，Domain在虚拟化技术里表示的不是CPU的状态，而是“域”，更通俗地说，就是一台虚拟机。

虽然从图1上看，Xen是运行在硬件之上的，但实际上，Xen严重依赖于一个特殊的Domain，那就是Domain 0。其实，Xen在发布其裸金属版本的时候，里面就包含了一个裁剪过的Linux内核，它为Xen提供了除CPU调度和内存管理之外的所有功能，包括硬件驱动、I/O、网络协议、文件系统、进程通信等所有其他操作系统所做的事情。这个Linux内核就运行在Domain 0 里面。这就是为什么当启动裸金属架构版的Xen时会自动启动Domain 0。因为没有这个Linux内核，Xen将无法工作。事实上，基于裸金属架构的VMM中往往包含了一个经过修改的Host OS。

因此，裸金属架构其实并不说明VMM能够抛开Host OS在硬件之上运行。如果我们把图1中的Domain 0放到与Xen Hypervisor平级的位置，或者放到Xen Hypervisor下面，Domain 0就与寄生架构没有区别了，如图2所示。而事实上，即使是寄生架构的产品，例如VirtualBox，在Host OS里面也会有一个运行于核心的驱动程序，它可以直接与物理设备打交道。

如果仔细看图2，会发现Domain 1和Domain 2与Domain 0之间还有一些通信。这与传统的寄生架构一样，Guest OS有时也是需要访问Host OS的。所以，裸金属架构本身不会给Guest OS的性能带来任何提升。

5案例

5.1深圳罗湖区统一电子政务云平台

罗湖电子政务平台建设总体思路是：以深化应用和注重成效为主线，转变电子政务发展方式，积极推动管理与信息化建设相融合，坚持整合政务信息资源，创新信息共享和业务协同模式，充分发挥云计算在全区资源共享、支撑能力、创新建设和服务模式等方面的特点。华为虚拟化给我们搭建好了这样一个平台。

——罗湖区信息中心

客户简介

罗湖，是广东深圳的一个市辖区，地处深圳中部，面积78.36 平方公里。目前下辖10 个街道，115 个社区，常住人口为92.45 万人。罗湖是深圳主要的金融区之一和商业中心区，著名的罗湖口岸，是中国目前客流量最大的旅客入出境陆路口岸，也是联结和内地的“第一口岸”，对外交往的窗口。

业务需求

近年来，世界各国纷纷提出转型战略，加速向“服务型”迈进，以顺应时代潮流的变化，希望打造成为开放、融合、高效、透明、绿色、安全的服务型智慧。在建设新型智慧的过程中，需要信息化技术的强有力支撑，过去几十年来以电子政务为核心的信息化建设取得了长足发展，但在发展过程及新形势的要求下，仍存在诸多问题，面临着严峻挑战。

在电子政务公共平台建设探索进行到一定程度，就需要通过建立适应电子政务应用的电子政务管理。以电子政务平台推广和应用为基础，推动流程优化和再造，全面梳理现行制度，将制度与现有的工作流程紧密结合起来，使两者的关系固化，才能保证电子政务系统可持续发展。

为推进电子政务发展，促进职能转变和管理创新，2013 年工信部确定首批基于云计算的电子政务公共平台建设和应用试点示范地区名单，深圳市福田区和罗湖区同时入选首批试点名单。

罗湖区打造电子的战略定位高举高打，提出基于云计算技术建设电子政务公共平台和应用。罗湖区虚拟化项目从全区资源应用的角度考虑，依托专业化、本地化的企业产品，建设全区统一管理和技术支撑的虚拟化平台，并对平台建设提出了思路和需求：

以深化应用和注重成效为主线， 转变电子政务发展方式，积极推动管理与信息化建设相融合；坚持整合政务信息资源，创新信息共享和业务协同模式，充分发挥云计算在全区资源共享、支撑能力、创新建设和服务模式等方面的特点；以罗湖区协同办公平台为枢纽，整合全区重要应用平台资源；以罗湖区协同办公平台工作流程为总引擎，整合全区各业务应用。改变以往以单个项目为主的建设模式，采用场地授权形式，全面提升已有计算资源的利用率。罗湖区信息中心表示，该项目的实施是罗湖区基于云计算的区电子政务大平台、大应用、大协同的一次宝贵尝试，能够极大提升罗湖区协同办公平台云应用核心支撑能力。

解决方案

在建设过程中，罗湖电子政务平台重点突出三大创新：流程创新、提升工作效率和实现精细化管理，用罗湖信息中心乐知主任的话说就是“流程走起来、业务串起来、过程记下来”。

原先的政务规划建设时都按照峰值业务进行采购配置，硬件资源利用率低、重复建设、无法实现资源和数据的集享。此外，业务连续性可靠性低，安全防护措施不足；硬件依赖性强， 系统上线部署时间长，统一监控管理难度大，运维管理成本高。为此，罗湖区电子政务中心找到华为，希望华为能够拿出一套切实可行的基础设施解决方案。

华为与客户多次沟通后，提出利用FusionSphere 云计算平台，实现政务30 多套业务的集中部署、资源共享的思路， 即可实现罗湖区云计算IAAS 平台全区计算资源、存储资源和网络资源集享，按需申请、弹性分配、统一运营监管。

同时，通过UltraVR容灾解决方案提升平台的业务连续性和可靠性，端到端安全策略设计，提升平台安全性。FusionManager统一管理监控平台软硬件，统一管理主站点与灾备站点，实现整个平台软硬件统一管理。

客户收益

该项目的实施全面解决了罗湖电子政务建设过程中几个突出问题：

彻底消除了“信息孤岛”，强化了业务协同和资源共享 ；

信息地流动更为顺畅；强化了业务协同，从重建设轻应用向深化应用和突出成效转变；突出资源共享，从分散重复建设向集约节约建设转变。

提高电子政务体系建设和管理效率，为“智慧罗湖”的“电子”宏大目标提供平台基础；

实现业务快速部署、平滑扩容，提高电子政务平台创新能力和服务能力；服务全区50多个一级单位，6000多用户，办件数量突破21万件，节约纸张超过500万张，树立国内电子政务云大平台的标杆。

电子政务历来有“三分技术，七分管理” 一说，电子政务建设的好与坏，推进得健康与否，很大程度上取决于推进的机制。同时能否建立适应电子政务应用的管理，还直接影响到电子政务效益发挥的高低。

降低运维成本，提高资源利用率，提升业务安全可靠性；

充分利用硬件资源，从原来的不足5%的资源使用率提升到70%，降低硬件投资达50%；提升整个平台统一运维、监控管理能力，降低业务部署复杂程度和维护成本；全双活容灾方案使业务更加安全可靠；

客户展望

“云平台的建设表面看起来是实行技术路线，但本质上是电子政务资源整合的重要抓手。云计算彻底改变了传统的建设模式、管理模式和应用模式。以往我们是‘物业管理处’， 现在相当于‘酒店’，要成为系统运行的责任单位，因此对我们提出更高的责任要求。”

二、SDN技术

1SDN网络介绍

1.1SDN定义

  SDN是一种新型的网络架构，它的设计理念是将网络的控制平面与数据转发平面进行分离，从而通过集中的控制器中的软件平台去实现可编程化控制底层硬件，实现对网络资源灵活的按需调配。在SDN网络中，网络设备只负责单纯的数据转发，可以采用通用的硬件;而原来负责控制的操作系统将提炼为的网络操作系统，负责对不同业务特性进行适配，而且网络操作系统和业务特性以及硬件设备之间的通信都可以通过编程实现。

1.2 SDN网络与传统网络的对比

与传统网络相比，SDN的基本特征有3点：

控制与转发分离。转发平面由受控转发的设备组成，转发方式以及业务逻辑由运行在分离出去的控制面上的控制应用所控制。

控制平面与转发平面之间的开放接口。SDN 为控制平面提供开放可编程接口。通过这种方式，控制应用只需要关注自身逻辑，而不需要关注底层更多的实现细节。

逻辑上的集中控制。逻辑上集中的控制平面可以控制多个转发面设备，也就是控制整个物理网络，因而可以获得全局的网络状态视图，并根据该全局网络状态视图实现对网络的优化控制。

1.3 SDN网络的意义

 需SDN不仅有益于网络，更有利于企业业务。通过控制平面和数据平面的可编程，将进一步控制企业投入的成本，并将加快企业业务的增长。说到这，就不得不提最初推动SDN发展的重要协议——OpenFlow，其将底层网络解耦为控制平面和数据平面，并通过控制端可编程，实现在任何时间重新编排任意数据包的传输路径。

  而除了OpenFlow之外，其他的SDN解决方案也提供了类似的功能，只不过是通过API来实现。这些API借助统一的命令和控制平台，实现对设备的配置和管理。目前其已广泛应用于数据中心和编排服务提供商，让网络可以直接支撑上层应用。

  其实无论是哪种方式，对于企业而言，都可通过网络控制层面的可编程性，实现自动化的网络配置和管理，从而降低专业技术人员的投入和运营成本。在数据平面，同样体现出可编程性的优势。其中在经典的OpenFlow SDN中，APP或插件借助控制器上标准的南向接口(API)，可实时更改数据流的网络行为。例如在控制器上加入IDS、IPS等安全插件，就是目前业界相当流行的新趋势。

  综合来看，控制平面可编程，更好地实现了网络自动化和编排，为企业提供更稳定高效的网络，并降低运营成本;与此同时，数据平面可编程，则可加速部署新服务，或快速修改已有服务，从而更好地支持新的应用。所以说，控制和数据平面可编程已经成为现代网络的趋势，因此企业必须要拥抱SDN。

2SDN和OPENFLOW

  从SDN的起源可以看出，OpenFlow协议是SDN实现控制与转发分离的基础。业界为了推动SDN发展并统一OpenFlow标准，组建了标准化组织开放网络基金会（OpenNetworking Fundation，ONF）。目前，ONF已成为SDN标准制定的重要推动力量，其愿景就是使基于OpenFlow协议的SDN成为网络新标准。openflow协议提供对SDN的实现支持，是对网络设备进行集中控制的规范标准，十一中南向的API接口。

2.1 OPENFLOW概念

  Openflow是软件定义网络的一个例子，指两个端点之间的网络连接是通过运行在外部电脑/服务器上的软件来定义的，而且硬件（交换机）上的指令行为基于控制器的智能决策。

2.2 OPENFLOW组件

openflow 最主要的组件是：openflow 控制器，openflow交换机，openflow协议。

     openflow控制器：是该协议的大脑，是所有基于业务流的智能决策点，并将决策发送给openflow支持的硬件交换机。这些决策以指令的形式存在与流表中。典型的flow流信息决策形式是：添加、删除及修改openflow交换机中的流表；通过配置openflow交换机，可以将所有未知数据包转发给控制器；也可以在openflow流表进行其他一些网络指令。

     openflow交换机：在硬件层面，openflow交换机类似于现在网络中使用的典型网络交换机。但其中不包含智能软件（OS）。在openflow交换机中，openflow控制器管理硬件的流表，交换机的性能主要是数据平面上的转发（ASIC处理）。数据通路（VLAN）由openflow控制器控制和管理，而数据通路则建立在由openflow控制器编址的ASIC指令基础之上。

     openflow协议：同其他网络协议一样，openflow协议的最终目标是传达控制数据通路的程序指令，但openflow实现数据通路指令的方法有所不同。openflow是客户端服务器技术和各种网络协议的同和体现。OF-CONFIG是配合openflow具体实现网络配置和管理的延伸协议。

2.3 Openflow流量转发

     Openflow的思路很简单，网络设备维护一个FlowTable并且只按照FlowTable进行转发，Flowtable本身的生成、维护、下发完全由外置的Controller来实现，注意这里的FlowTable并非是指IP五元组，事实上OpenFlow 1.0定义的了包括端口号、VLAN、L2/L3/L4信息的10个关键字，但是每个字段都是可以通配的，网络的运营商可以决定使用何种粒度的流，比如运营商只需要根据目的IP进行路由，那么流表中就可以只有目的IP字段是有效的，其它全为通配。

 这种控制和转发分离的架构对于L2交换设备而言，意味着MAC地址的学习由Controller来实现，V-LAN和基本的L3路由配置也由Controller下发给交换机。对于L3设备，各类IGP/EGP路由运行在Controller之上，Controller根据需要下发给相应的路由器。流表的下发可以是主动的，也可以是被动的，主动模式下，Controller将自己收集的流表信息主动下发给网络设备，随后网络设备可以直接根据流表进行转发;被动模式是指网络设备收到一个报文没有匹配的FlowTable记录时，将该报文转发给Controller，由后者进行决策该如何转发，并下发相应的流表。被动模式的好处是网络设备无需维护全部的流表，只有当实际的流量产生时才向Controller获取流表记录并存储，当老化定时器超时后可以删除相应的流表，故可以大大节省TCAM空间。当一个Controller同时控制多个交换机/路由器设备时，它们看起来就像一个大的逻辑交换机，各个交换机/路由器硬件就如同这个逻辑网络设备的远程线卡，类似的概念在Cisco的Nexus 1000/1000v、ASR9000/9000v和Juniper的Q-Fabric架构中可以看到影子，Cisco称之为nV(Network Virtualization)技术。

3VxLAN 介绍

3

3.1什么是VXLAN

VXLAN（Virtual Extensible LAN）虚拟可扩展局域网， 是一种overlay网络技术，将原始2层以太网帧进行UDP封装(MAC-in-UDP)，增加8字节VXLAN头部，8字节UDP头部，20字节IP头部和14字节以太网头部，共50字节。

3.2 VXLAN优点

    VXLAN与VLAN相比能够提供更好的扩展性和灵活性，主要有以下特点：

应用灵活部署：通过VXLAN封装后的2层以太网帧可以跨3层网络边界，让组网以及应用部署变得更加灵活，同时解决多租户网络环境中IP地址冲突问题。

更好的扩展性：传统VLAN ID字段为12-bit，VLAN数量最大为4096；VXLAN使用24-bit VNID（VXLAN network identifier），最大支持16,000,000逻辑网络。

提高网络利用率：传统以太网使用STP预防环路，STP导致网络冗余路径处于阻塞状态，VXLAN报文基于3层IP报头传输，能有效利用网络路径，支持ECMP（equal-cost multipath ）和链路聚合协议。

3.2.1应用灵活部署

图1-1 使用VXLAN后可灵活部署应用，不受物理位置和3层网络边界

如图1-1所示，在VXLAN环境中应用部署不受物理位置和3层网络边界，例如某应用的地址段为192.168.1.0/24，在传统网络中所有该应用服务器或者虚拟机必须在同一3层网络内部署，否则会产生路由或者地址冲突问题。

3.2.2更好的扩展性

图1-2 使用VXLAN后突破传统VLAN数量

 传统网络通过VLAN将客户网络逻辑隔离，VLAN ID字段为12-bit，VLAN数量最大为4096；VXLAN使用24-bit VNID（VXLAN network identifier），最大支持16,000,000逻辑网络，扩展性得到极大增强。

3.2.3 提高网络利用率

图1-3 使用VXLAN后使用三层接口互联消除生成树阻塞端口

传统以太网帧无法穿越三层网络，部署VXLAN后，VTEP之间数据基于三层寻址，网络互联接口不再是二层接口，可以将交换机之间互联接口部署为三层模式，消除生成树阻塞端口，提高网络利用率，支持ECMP（equal-cost multipath ）和链路聚合协议。

3.3 VxLAN 需求

服务器的驶入将被抽象到交换机/路由器为基础的网络中，与openflow不同（该开关时可编程的），这项技术专注于虚拟机之间的终端到终端之间的通信，而虚拟机是有网络边界所隔离。

服务器虚拟化导致网络上活跃着数量庞大的虚拟机（VM），这正造成现有的网络基础设施找到一个是需求增长的方法。随着虚拟备分割成组，数据中心每分每秒都在增长。原来这都是使用vlan来完成的。然而，4094个vlan可能不足够应付这种增长的需求。数据中心共托管多个租户，每个租户都有自己的应用程序。每个租户都是自己的逻辑网络。

以一个虚拟机操作为例。随着虚拟化和云计算的诞生，虚拟机可以从一台服务器无缝迁移到另一个上去，并且对被移动的虚拟机没有任何影响。然而，在目前的设计中，只有VM是在相同的IP子网上，这才能达到。这个将不会允许虚拟机跨过不同的IP子网移动，并且随着数据中心的规模和复杂性增长，这可能是一个重大的问题。

    VxLAN（虚拟可扩展局域网）是基于已有网络基础设施运行，提供基于三层网络技术承载二层网络传输的方法。vxlan也被称为用三层覆盖二层网络的技术方案，即overlay方案。单个overlay被称为一个vxlan segment，在相同vxlan segment的虚拟机可以互相通信。

3

3.4

3.4

3.4

3.4 VxLAN 术语

VNI（虚拟网络标识符）：这是一个24位的ID。vni标识一个vxlan。这给出了将近16M可以使用的vxlans。vni将内部的帧封装（帧起源在虚拟机）。使用vni封装有助于vxlan建立tunnel，该tunnel在第三层网络之上覆盖第二层网络。

VTEP（vxlan tunnel end point）：这条tunnel发起于一个称为vxlan tunnel end point。该tunnel从一个VTEP延伸到另一VTEP，并且由vni识别。VTEP将从虚拟机发出/接受的帧封装/解封装，而虚拟机并不区分vni和vxlan tunnel。

3.5  VXLAN封装

VXLAN使用UDP封装完整的以太网帧(MAC-in-UDP)，共50字节的封装报文头。具体的报文格式如下：

图1-4 VXLAN封装格式

Inner MAC

Inner MAC，内层MAC是原始以太网帧的MAC地址。

VXLAN Header

共8个字节，目前使用的是Flags中的一个8bit的标识位和24bit的VNI(Vxlan Network identifier)，其余部分没有定义，但是在使用的时候必须设置为0x0000。

Outer UDP Header

共8个字节，IANA分配的标准目的端口使用4798，但是各厂商可以根据需要进行修改，同时UDP的校验和必须设置成全0。

Outer IP Header

共20个字节，目的IP地址可以是单播地址，也可以是多播地址。单播情况下，目的IP地址是目的VTEP的IP地址；当用于VXLAN控制平面时会使用多播地址。

Outer IP:外层IP地址是经过VTEP封装后的3层IP地址，源IP是本端VTEP设备IP，用于控制平面时目的IP可以是多播地址，用于转发平面时目的IP是远端VTEP设备IP。

Outer Ethernet Header

共计14个字节，外层以太网帧头部。Outer MAC，外层MAC是经过VTEP封装后的二层MAC，源MAC是本端VTEP设备MAC，目的MAC可以是远端VTEP设备MAC或者传输路径中间3层网络设备MAC。

3

3.1

3.2

3.3

3.4

3.5

3.6 VXLAN数据转发

3.6.1控制平面

在VXLAN的实现中，当通过组播实现控制平面路径发现时，VTEP设备之间使用无状态tunnel，VTEP设备之间不会维持状态化的长连接。VXLAN需要通过控制平面学习远端设备地址信息，在本地构建控制平面表项。控制平面表项由VNI、Inner Source MAC、Outer Source IP三元组组成。

3

3.6

3.6

3.6

3.6

3.6

3.6

3.6.1

3.6.2转发平面

控制平面学习地址映射信息后，转发平面负责实际数据的转发。VTEP为原始数据帧增加UDP报头，新的报头到达目的VTEP后才会被去掉，中间路径的网络设备只会根据外层包头内的目的地址进行数据转发。

3.6.3VXLAN ARP请求

图1-4 VXLAN网络MAC地址学习

如上图所示，终端设备A需要和终端设备B通信，ARP请求过程如下：

1、终端设备A发送ARP请求，请求终端设备B的MAC地址；

2、VTEP-1收到终端设备A发送的ARP请求，此时VTEP-1还没有终端设备B对应的地址映射表项，VTEP-1将ARP请求进行VXLAN封装，VNI设置为10，outer-src-ip是VTEP-1的IP，outer-dst-ip是加入的组播组地址，封装完成后转发至VXLAN组播组；

3、VTEP-2、VTEP3加入相同的组播组，所有组成员都会收到VTEP-1发送的组播报文，解封装后检查VNI与本地VNI是否匹配，如匹配将ARP请求发送至本地网络，同时记录VNI、inner MAC、outer IP的对应关系，构建控制平面地址映射表项。如VNI不匹配则丢弃数据包。

4、终端设备B收到ARP请求后以单播方式发送ARP响应；

5、VTEP-2收到终端设备B的ARP响应后进行VXLAN封装，此时VTEP-2已经构建控制平面地址映射表项，通过VXLAN封装后以单播方式发送。Outer-src-ip是VTEP-2的IP地址，outer-dst-ip是VTEP-1的IP地址；

6、VTEP-1收到封装后的ARP响应后，解封装比对VNI，如匹配将ARP响应发送至终端设备A，同时记录VNI、inner MAC、outer IP的对应关系，构建控制平面表项；

7、此时VTEP-1、VTEP-2均已成功构建控制平面地址映射信息，后续VXLAN数据使用单播在VTEP-1和VTEP-2之间传输。

3

3.1

3.2

3.3

3.4

3.5

3.6

3.6.1

3.6.2

3.6.3

3.6.4VXLAN 数据传输

ARP请求完成后，终端设备A向终端设备B发送数据，VTEP-1收到数据中查找地址映射表项，将原始数据进行VXLAN封装后转发至VTEP-2；

VTEP-2收到VXLAN数据包后检查VNI是否与本地VNI匹配，如匹配则解封装后将原始以太网帧转发至终端设备B。

3.7 补充

在进行ARP处理时，为了将广播通过多播进行传输，必须要设置VNI到多播组的映射，这种映射属于管理层，用于建立VTEP之间的管理通道。未知的目的MAC（unknown MAC destination）同样会进行组播封装，处理方式和广播相同。

VXLAN报文不能进行分片处理，中间的设备可能会将VXLAN报文分片，但是VTEP会将分片后的报文丢弃，为了确保VXLAN报文不被分片处理，需要修改沿途所以设备的MTU。RFC文档没有阐述为什么VTEP必须丢弃分片后的报文。

在封装和解封装时VLAN TAG信息都会被剥离，除非另有特殊配置。

4SDN典型架构

4.1SDN体系架构

 SDN的典型架构共分三层，最上层为应用层，包括各种不同的业务和应用;中间的控制层主要负责处理数据平面资源的编排，维护网络拓扑、状态信息等;最底层的基础设施层负责基于流表的数据处理、转发和状态收集。其包含的组件有：

    控制器：控制器集中管理网络中所有设备，虚拟整个网络为资源池，根据用户不同的需求以及全局网络拓扑，灵活动态的分配资源。SDN控制器具有网络的全局视图，负责管理整个网络：对下层，通过标准的协议与基础网络进行通信；对上层，通过开放接口向应用层提供对网络资源的控制能力。

    SDN应用层：SDN应用层通过控制层提供的编程接口对底层设备进行编程，把网络的控制权开放给用户，基于上开发各种业务应用，实现丰富多彩的业务创新。

    物理层：物理层是硬件设备层，专注于单纯的数据、业务物理转发，关注的是与控制层的安全通信，其处理性能一定要高，以实现高速数据转发。

    南向接口：南向接口是物理设备与控制器信号传输的通道，相关的设备状态、数据流表项和控制指令都需要经由SDN的南向接口传达，实现对设备管控。

北向接口：北向接口是通过控制器向上层业务应用开放的接口，目的是使得业务应用能够便利地调用底层的网络资源和能力，其直接为业务应用服务的，其设计需要密切联系业务应用需求，具有多样化的特征。

目前比较成熟的DNS产品有vmware的NSX及思科的ACI应用解决方案。

NSX是基于hypervisor平台，在其esxi内核中实现。对于数据包的封装/解封装都是通过ESIX内核处理的。数据层面在ESXI安装插件实现虚拟交换机、虚拟路由器、虚拟防火墙等功能。NSX controller是一个高级分布式管理系统，提供控制层面功能实现逻辑交换和逻辑路由。管理层面由NSX manager构建，是NSX集中式网络管理，提供单个配置点和REST API入口点。应用层面由vsphere web client中的NSX manager用户界面查看，将网络虚拟化与其云管理平台相融合，以部署应用。

思科 ACI是数据中心互联矩阵，基于硬件平台，使用分离的组件，实现交换和路由功能，即数据是分布式转发的，控制是集中式的。数据层面的数据包及VXLAN的封装解封装及策略的分发都是通过ASIC指令完成。控制层面的控制器叫做APIC，分布式连接至leaf switchs上，是矩阵的中心管理端，通过在APIC上配置模版，它再分布ANP策略到矩阵的边界设备。leaf switch可以连接服务器也可以连接防火墙、负载均衡（包含vFW等）等设备，在应用层面提供了一组网络负载及工作负载。 

1

2

3

4

4.1

4.2 SDN特性及作用

    SDN本质上具有“控制和转发分离”、“设备资源虚拟化”和“通用硬件及软件可编程”三大特性，这至少带来了以下好处。

   设备硬件归一化,硬件只关注转发和存储能力，与业务特性解耦，可以采用相对廉价的商用的架构来实现。

   网络的智能性全部由软件实现,网络设备的种类及功能由软件配置而定,对网络的操作控制和运行由服务器作为网络操作系统(NOS)来完成。

   对业务响应相对更快,可以定制各种网络参数，如路由、安全、策略、QoS、流量工程等，并实时配置到网络中，开通具体业务的时间将缩短。

三、分布式存储

1技术背景

目前互联网上可访问的信息数量接近1秭= 1百万亿亿 (1024)。毫无疑问，各个大型网站也都存储着海量的数据，这些海量的数据如何有效存储，是每个大型网站的架构师必须要解决的问题。分布式存储技术就是为了解决这个问题而发展起来的技术，下面让将会详细介绍这个技术及应用。

海量数据是指数据量极大，往往是Terabyte(10^12bytes)、Petabyte(10^15bytes)甚至Exabyte(10^18bytes)级的数据集合。

存储这些海量信息不但要求存储设备有很大的储存容量，且还需要大规模数据库来存储和处理这些数据，在满足通用关系数据库技术要求的同时，更需要对海量存储的模式、数据库策略及应用体系架构有更高的设计考虑。

存储系统的存储模式影响着整个海量数据存储系统的性能，为了提供高性能的海量数据存储系统，应该考虑选择良好的海量存储模式

对于海量数据而言，实现单一设备上的存储显然是不合适的，甚至是不可能的。分布式是解决这种问题的一个很好的解决方案。

                        存储分类（根据服务器类型）

2分布式存储的特点

2.1分布式存储概念

与目前常见的集中式存储技术不同，分布式存储技术并不是将数据存储在某个或多个特定的节点上，而是通过网络使用企业中的每台机器上的磁盘空间，并将这些分散的存储资源构成一个虚拟的存储设备，数据分散的存储在企业的各个角落。

2.2具体技术及应用

海量的数据按照结构化程度来分，可以大致分为结构化数据，非结构化数据，半结构化数据。 

本文接下来将会分别介绍这三种数据如何分布式存储。

2.3结构化数据的存储及应用

所谓结构化数据是一种用户定义的数据类型，它包含了一系列的属性，每一个属性都有一个数据类型，存储在关系数据库里,可以用二维表结构来表达实现的数据。

大多数系统都有大量的结构化数据，一般存储在Oracle或MySQL的等的关系型数据库中，当系统规模大到单一节点的数据库无法支撑时，一般有两种方法：垂直扩展与水平扩展。

垂直扩展：垂直扩展比较好理解，简单来说就是按照功能切分数据库，将不同功能的数据，存储在不同的数据库中，这样一个大数据库就被切分成多个小数据库，从而达到了数据库的扩展。一个架构设计良好的应用系统，其总体功能一般肯定是由很多个松耦合的功能模块所组成的，而每一个功能模块所需要的数据对应到数据库中就是一张或多张表。各个功能模块之间交互越少，越统一，系统的耦合度越低，这样的系统就越容易实现垂直切分。 

水平扩展：简单来说，可以将数据的水平切分理解为按照数据行来切分，就是将表中的某些行切分到一个数据库中，而另外的某些行又切分到其他的数据库中。为了能够比较容易地判断各行数据切分到了哪个数据库中，切分总是需要按照某种特定的规则来进行的，如按照某个数字字段的范围，某个时间类型字段的范围，或者某个字段的hash值。

    垂直扩展与水平扩展各有优缺点，一般一个大型系统会将水平与垂直扩展结合使用。

    实际应用：图1是为核高基项目设计的结构化数据分布式存储的架构图。 

图1可水平&垂直切分扩展的数据访问框架

∙ 采用了的分布式数据访问层，后端分布式数据库集群对前端应用透明。

∙ 集成了Memcached集群，减少对后端数据库的访问，提高数据的查询效率。

∙ 同时支持垂直及水平两种扩展方式。

∙ 基于全局唯一性主键范围的切分方式，减轻了后续维护的工作量。

∙ 全局唯一性主键的生成采用DRBD+Heartbeat技术保证了可靠性。

∙ 利用MySQL Replication技术实现高可用的架构。

     注:以上的数据切分方案并不是唯一扩展MySql的方法，有兴趣的读者可以关注一下” 云计算时代的MySQL-Clustrix Sierra分布式数据库系统”。

2.4非结构化数据的存储及应用

相对于结构化数据而言,不方便用数据库二维逻辑表来表现的数据即称为非结构化数据,包括所有格式的办公文档、文本、图片、XML、HTML、各类报表、图像和音频/视频信息等等。

分布式文件系统是实现非结构化数据存储的主要技术，说到分布式文件系统就不得不提GFS（全称为"Google File System"），GFS的系统架构图如下图所示。

图2 Google-file-system架构图

图3 Google-file-system架构图（详细）

GFS将整个系统分为三类角色：Client（客户端）、Master（主服务器）、Chunk Server（数据块服务器）。

∙ Client（客户端）：是GFS提供给应用程序的访问接口，它是一组专用接口，不遵守POSIX规范，以库文件的形式提供。应用程序直接调用这些库函数，并与该库链接在一起。

∙ Master（主服务器）：是GFS的管理节点，主要存储与数据文件相关的元数据，而不是Chunk（数据块）。元数据包括：命名空间（Name Space），也就是整个文件系统的目录结构，一个能将位标签映射到数据块的位置及其组成文件的表格，Chunk副本位置信息和哪个进程正在读写特定的数据块等。还有Master节点会周期性地接收从每个Chunk节点来的更新（"Heart- beat"）来让元数据保持最新状态。

∙ Chunk Server（数据块服务器）：负责具体的存储工作，用来存储Chunk。GFS将文件按照固定大小进行分块，默认是MB，每一块称为一个Chunk（数据块），每一个Chunk以Block为单位进行划分，大小为KB，每个Chunk有一个唯一的位标签。GFS采用副本的方式实现容错，每一个Chunk有多个存储副本（默认为三个）。 Chunk Server的个数可有有多个，它的数目直接决定了GFS的规模。

GFS之所以重要的原因在于，在Google公布了GFS论文之后，许多开源组织基于GFS的论文开发了各自的分布式文件系统，其中比较知名的有HDFS，MooseFS，MogileFS等。

实际应用：由于核高基的项目中未来会有大量的数据与应用需要存储，所以我们设计时也采用分布式文件系统的方案，由于开源的分布式文件系统可以基本满足我们需求，另外从时间上来说也比较紧张，所以我们采用了开源的MooseFS作为底层的分布式文件系统。

∙ MooseFS存在的问题：由于MooseFS是也是按照GFS论文设计的，只有一个Master（主服务器），虽然可以增加一个备份的日志服务器，但是还是存在Master无法扩展的问题，当单一Master节点上存储的元数据越来越多的时候，Master节点占用的内存会越来越多，直到达到服务器的内存上限，所以单一Master节点存在内存上的瓶颈，只能存储有限的数据，可扩展性差，并且不稳定。

∙ 对MooseFS的优化：面对MooseFS存在的问题，我们采用了类似分布式数据库中的“Sharding”技术，设计了一个分布式文件系统访问框架，可以做到对分布式文件系统做垂直与水平切分。这样就最大限度的保证了MooseFS系统的可扩展性与稳定性。

下图是为核高基项目设计的非结构化数据分布式存储的架构图。我们设计了两种访问方式，一种是类似GFS的API访问方式，以库文件的方式提供，应用程序通过调用API直接访问分布式文件系统。第二种是通过RESTful web Service访问。

图4可水平&垂直切分扩展的分布式文件系统访问框架（API版）

图5可水平&垂直切分扩展的分布式文件系统访问框架（RESTful web Service版）

2.5半结构化数据的存储及应用

就是介于完全结构化数据（如关系型数据库、面向对象数据库中的数据）和完全无结构的数据（如声音、图像文件等）之间的数据， 半结构化数据模型具有一定的结构性，但较之传统的关系和面向对象的模型更为灵活。半结构数据模型完全不基于传统数据库模式的严格概念，这些模型中的数据都是自描述的。

由于半结构化数据没有严格的schema定义，所以不适合用传统的关系型数据库进行存储，适合存储这类数据的数据库被称作“NoSQL”数据库。

NoSQL的定义：

被称作下一代的数据库，具有非关系型，分布式，轻量级，支持水平扩展且一般不保证遵循ACID原则的数据储存系统。“NoSQL”其实是具有误导性的别名，称作Non Relational Database(非关系型数据库)更为恰当。所谓“非关系型数据库”指的是： 

∙ 使用松耦合类型、可扩展的数据模式来对数据进行逻辑建模(Map，列，文档，图表等)，而不是使用固定的关系模式元组来构建数据模型。

∙ 以遵循于CAP定理（能保证在一致性，可用性和分区容忍性三者中中达到任意两个）的跨多节点数据分布模型而设计，支持水平伸缩。这意味着对于多数据中心和动态供应（在生产集群中透明地加入/删除节点）的必要支持，也即弹性(Elasticity)。

∙ 拥有在磁盘或内存中，或者在这两者中都有的，对数据持久化的能力，有时候还可以使用可热插拔的定制存储。

∙ 支持多种的‘Non-SQL’接口(通常多于一种)来进行数据访问。

图6是Sourav Mazumder提出的NoSQL总体架构：

图6 NoSQL总体架构

∙ 接口：REST (HBase，CouchDB，Riak等)，MapReduce (HBase，CouchDB，MongoDB，Hypertable等)，Get/Put (Voldemort，Scalaris等)，Thrift (HBase，Hypertable，Cassandra等)，语言特定的API(MongoDB)。

∙ 逻辑数据模型：面向键值对的(Voldemort，Dynomite 等)，面向Column Family的(BigTable，HBase，Hypertable 等)，面向文档的(Couch DB，MongoDB等)，面向图的(Neo4j， Infogrid等)

∙ 数据分布模型：致性和可用性(HBase，Hypertable， MongoDB等)， 可用性和可分区性(Cassandra等)。一致性和可分区性的组合会导致一些非额定的节点产生可用性的损失。有趣的是目前还没有一个“非关系型数据库”支持这一组合。

∙ 数据持久性：基于内存的(如Redis，Scalaris， Terrastore)，基于磁盘的(如MongoDB，Riak等)，或内存及磁盘二者的结合(如 HBase，Hypertable，Cassandra)。存储的类型有助于我们辨别该解决方案适用于哪种类型。然而，在大多数情况下人们发现基于组合方 案的解决方案是最佳的选择。既能通过内存数据存储支持高性能，又能在写入足够多的数据后存储到磁盘来保证持续性。

NoSQL中的重要理论基础：

CAP理论：

∙ C: Consistency 一致性

∙ A: Availability 可用性(指的是快速获取数据)

∙ P: Tolerance of network Partition 分区容忍性(分布式)

图7 CAP理论

CAP原理告诉我们，这三个因素最多只能满足两个，不可能三者兼顾。对于分布式系统来说，分区容错是基本要求，所以必然要放弃一致性。对于大型网站来说，分区容错和可用性的要求更高，所以一般都会选择适当放弃一致性。对应CAP理论，NoSQL追求的是AP，而传统数据库追求的是CA，这也可以解释为什么 传统数据库的扩展能力有限的原因。

  BASE模型：

说起来很有趣，BASE的英文意义是碱，而ACID是酸。真的是水火不容啊。

∙ Basically Availble –基本可用

∙ Soft-state –软状态/柔性事务

∙ Eventual Consistency –最终一致性

BASE模型是传统ACID模型的反面，不同于ACID模型，BASE强调牺牲高一致性，从而获得可用性或可靠性。

基本可用是指通过Sharding，允许部分分区失败。

软状态是指异步，允许数据在一段时间内的不一致，只要保证最终一致就可以了。

最终一致性是整个NoSQL中的一个核心理念，强调最终数据是一致的就可以了，而不是时时一致。

Quorum NRW：

图8 Quorum NRW

N: 复制的节点数，即一份数据被保存的份数。 

R: 成功读操作的最小节点数，即每次读取成功需要的份数。 

W: 成功写操作的最小节点数 ，即每次写成功需要的份数。

这三个因素决定了可用性，一致性和分区容错性。只需W + R > N，就可以保证强一致性。

实际应用： 今年上半年我在aspire的搜索团队中负责互联网搜索的设计与开发，我设计的网页爬虫系统就是采用Cassandra来存储网页与链接信息的。下面结合我的实际使用经验谈谈我对Cassandra的看法：

优点：

∙ 弹性扩展：由于Cassandra是完全分布式的，使用时不需要再像使用MySQL那样自己设计复杂的数据切分方案，也不再配置复杂的DRBD+Heartbeat，一切都变得非常简单了，只需要简单的配置就可以给一个集群中增加一个新的节点，而且对客户端完全是透明的，不需要任何更改。

∙ 灵活的schema：不需要象数据库一样预先设计schema，增加或者删除字段非常方便。

∙ 使用简单：由于没有类似SQL这样复杂的查询语言，学习成本不高，很容易上手。

缺点：

∙ 稳定性差：在我们的实际使用过程中发现，单机数据量达到200G以上，时不时就会发生宕机现象。

∙ 缺乏管理与分析工具：传统的关系型数据都有比较好用的管理与分析工具，使用这些工具可以轻松的管理数据库，查看数据，分析性能瓶颈等，而Cassandra确缺少类似的工具，就连简单的查看一条数据，都要通过编程才能看到。

3与传统存储比较的优劣

这两种存储架构并没有绝对的优劣之分。一方面，传统存储阵列以可靠性高、稳定性好，功能丰富而著称，并在以往应用实践中得到了广泛认可。但与此同时，传统存储阵列也暴露出了横向扩展性差、价格昂贵、弹性缺乏、数据连通困难等不足，容易形成数据孤岛，导致数据中心管理和维护的成本居高不下。

集中存储的优缺点是，物理介质集中布放;视频流上传到中心对机房环境要求高，要求机房空间大，承重、空调等都是需要考虑的问题。 

分布存储，集中管理的优缺点是，物理介质分布到不同的地理位置;视频流就近上传，对骨干网带宽没有什么要求;可采用多套低端的小容量的存储设备分布部署，设备价格和维护成本较低;小容量设备分布部署，对机房环境要求低。 

分布式存储系统，就是将数据分散存储在多立的设备上。传统的网络存储系统采用集中的存储服务器存放所有数据，存储服务器成为系统性能的瓶颈，也是可靠性和安全性的焦点，不能满足大规模存储应用的需要。分布式网络存储系统采用可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息，它不但提高了系统的可靠性、可用性和存取效率，还易于扩展。

传统的集中方式无法满足大规模数据存取的要求，就需要采用新的体系来管理系统中的数据。分布式存储系统可以利用大量节点的计算和带宽资源用于数据存取，具有弱结构化、没有单一故障点、可靠性好、易于扩展、数据吞吐率高等优点。

传统存储阵列发展的几十年里，确实给数据中心的建设带来了巨大的发展，但是随着虚拟化的普及以及大数据、云计算、互联网+等等概念的落实，传统存储阵列的疲态凸显，在处理能力、扩展性、可维护性、可靠性方面，以及成本考量都呈现出更多地劣势。存储厂商一味在增强、扩大这个“铁盒子”，维护传统领域“蛋糕”的同时，也在加紧研究着另一种背道而驰的存储技术，这就是分布式存储技术。分布式存储技术相对传统存储阵列来说，具有以下一些明显优势：

1、简单化。传统存储阵列需要一台昂贵的硬件，以及相应的存储交换机、HBA等专用配件，对于存储阵列的配置需要专业的人员进行管理，甚至受制于存储厂商。而VMware分布式存储技术，直接利用了服务器的磁盘，服务器本身就是控制器，在数据中心的架构中，减少了整整一个存储硬件层面，大大简化了数据中心建设的复杂程度。

2、性能的保障。

传统存储之前的优势是性能，但是这一点已经被，对于绝大部分中低端存储来说，性能反而一直是一个“鸡肋”，在虚拟化环境中，由于集中化了I/O处理，而且I/O处理是共享式的，因此很可能造成对于某些虚拟机的影响，或者干脆由于整体性能不行拖累了虚拟化平台。分布式存储技术的性能，取决于高速缓存的处理能力和大小，而它采用的是固态盘技术（SSD），单块SSD的性能可达上万IOPS，如果组建集群的话，性能可以线性扩充，这大大缓解了性能瓶颈。Developers。

3、扩展性的优势。

分布式存储的优势就是“分布式”，所谓的“分布式”就是能够将多个物理节点整合在一起形成共享的存储池，节点可以线性扩充，这样可以源源不断的通过扩充节点提升性能和扩大容量，这是传统存储阵列无法做到的。

4、面向对象的管理。

这里所提到的“对象”，是虚拟机，传统存储阵列都是“块”一级的操作，存储规则的定义与虚拟机、应用无任何关联性，这就造成存储与应用、业务系统的脱节，而新一代的分布式存储技术，所有的存储规则都可以定义到虚拟机级别，每个虚拟机都可以有自己的个性化的存储规则，比如“副本的多少、条带化、存储格式”等等，这才真正做到存储层面与应用的互动，“存储感知应用”，及时为业务系统创造合适的存储环境。

5、更高的可靠性。

由于分布式存储的架构是分散式的，数据的存放也是分散在不同的节点之上，因此如果个别节点的损坏，对于整体架构没有任何影响。“单点故障”是一直是困扰传统存储阵列最大的问题，而配置多台存储阵列做镜像的意义不大，同时成本不菲，而分布式存储技术轻松的解决了这个问题。尤其是跨站点的VSAN技术出来之后，使得这种可靠性扩展到了容灾级别。6、更好的维护能力。

这里所提到的维护，指的是维护硬件，传统存储架构中，如果出现了故障，我们要逐层排查故障点，其中比较复杂的层面就是存储阵列和存储网络，因为这是专业的领域，需要所谓的专家们来配合解决，而分布式存储技术，由于与虚拟化内核紧密耦合，服务器层就是存储层，并且通过虚拟化管理软件可以一览无余的看到分布式存储的状态，因此对于整体维护来说非常方便。7、更低的成本

成本这件事，真不好说，现在中低端存储的价格，尤其是某些非主流品牌的存储阵列确实比较便宜，相比之下或许VSAN还没有占尽优势，这也给传统的存储厂商一些可操作空间，花钱买个“鸡肋”划算，还是买个放心呢。IT Managers，看你们的议价能力了。

简而言之，分布式存储的优势就是“更快更省更简单”，当然这里所说的分布式存储，特指的是VMware VSAN，其它开源类分布式技术可要另当别论。理想主义伟人马克思说道“这世界唯一不变的就是变化”。中国古人也很早就预测了这一时刻的到来，他们时常劝诫世人“与人为善、予人VSAN......”，你听懂了吗。

对于分布式存储一直有一个疑问：横向扩展(Scale Out)、弹性伸缩、敏捷业务、开箱即用，外加成本优势……，无不针对传统存储的“罩门”，从技术分析上看，分布式存储理应所向披靡，但为什么现实市场并不是这样呢？

超融合产业联盟联想企业云产品总监高志国对此有一个观点认为：分布式存储发展不会一步登天，会有一个过程。首先分布式存储会蚕食增量存储市场，然后随着用户对于技术理解的不断加深，最终将一统江湖。分布式存储称雄市场是早晚的事情。“当务之急是团结合作，打败共同的敌人--传统存储。”这是超融合产业联盟倡导的产业情怀和志向。

当我们在谈论超融合存储、传统存储的时候，其实有一个隐性的前提：分布式存储和传统存储是对立的。但真的是这样吗？对此，有着15年存储业界经验的老兵--宏杉科技总裁李治就曾经说过曾经说过：传统存储V.S分布式存储的对比是不合适的，分布式并不是超融合的专利，传统阵列存储也可以采取分布式。

众所周知，传统存储以EMC、HDS、NetApp为代表，产品方案以SAN和NAS应用为主。典型SAN应当属关系型数据库，数据以块数据为主，所谓结构化数据；而NAS以文件数据为主，可以认为是非结构化数据。期间，也有所谓融合存储或称统一存储，用单一阵列兼顾AN和NAS应用，所谓SAN+NAS。

实际上，传统阵列存储也在向软硬件分离方向发展，也是一种软件定义存储的方式。在新的方式下，统一存储不需额外添加NAS机头，用软件方式来实现。

分布式存储方面，以对象存储、云存储、超融合、ServerSAN……为主，以x86本地存储为核心，构建统一资源池共享存储。鉴于x86服务器+磁盘价格优势明显，因此备受关注。

其实仅仅从架构上很难分辨二者的差别，因此也可以从应用角度对比一下。

分布式存储实践多来自互联网企业的云计算中心，而传统阵列存储主要应用在行业/企业级的数据中心。应用类型方面，互联网以门户网站、IM、搜索、游戏、邮箱应用为主，其特点是：种类相对不多，但单一应用的规模巨大，可以达到千万甚至数以亿计；企业级用户方面，应用以OLTP、OLAP、OA、ERP、CRM等为主，应用种类丰富，但单一应用的规模并不大，有些应用的规模就是几十人。

应用性质不同，其对于存储性能的需求也不尽相同。以OLTP为例，除了IOPS之外，对于低时延的要求也很高。对此，分布式存储可以应对吗？

也许会有人会说到“双11”，电子商务不也是OLTP性质的应用吗？确实，电商也是一种关键业务应用。在技术上，电商主要针对浏览、查询，也就是前端的应用进行了分流，属于一种分库、分表的操作，数据之间并不要求严格的数据一致性。有消息称，电商核心交易部分也是采用传统阵列存储。

不论如何，分布式存储给传统行业/企业带来的冲击是巨大的，从传统阵列一枝独秀，到传统存储、分布式存储分庭抗礼，其实用户乐享其成，不是吗？

分布式存储和传统存储相互竞争也相互借鉴。分布式存储在横向扩展和成本上优势明显，但是要求传统/行业企业在应用上进行必要的调整。例如用业务的手段来规避数据非一致性带来的问题，如双11期间，电商没有办法第一时间退款等。

对于传统行业/企业来说，大多会采用服务外包的模式，主要依靠合作伙伴的技术力量，企业自身的技术人员有限。在这样的情况下，需要提供更好的技术支持和服务。与此同时，传统阵列存储也不会一成不变。

传统阵列存储主要的短板在于Scale Out能力相对有限，随着时间的推移就会形成一个个的信息孤岛，能不能打破这种不利的局面呢？其实，分布式存储给传统阵列存储带来了很好的借鉴。

在保持稳定、可靠、高性能和低延迟特点的同时，如果传统存储也可以实现控制器(机头)计算和存储资源池的管理和调度，如此传统存储也就是实现了转型和升级。

4案例

4.1FusionStorage助力浙江电信建设PB级SDS

   客户简介

业务挑战

 放性的存储服务？如何解决面对多厂家高端存储并存下的高昂的运维、扩容成本？已经成为实现“按需分配”的云资源池核心理念、实现整个战略转型的关键技术难题。

解决方案

顾炯说，分布式存储是传统SAN 存储（Storage Area Network）的演进方向。有了这个需求以后，浙江电信13年10 月份开始寻找合作伙伴。

“像有一些厂家是拿对象存储封装成块存储的协议，或者是拿文件存储封装成块存储的协议，性能完全不够。”顾炯说，业界真正能够做到分布式块存储的，只有华为和EMC。

分布式存储架构解决了传统架构的I/O 瓶颈

目前，浙江电信的WAP网关、网规网优业务均已经在该系统上稳定运行。华为分布式存储在浙江电信实测的单盘性能是普通SATA盘的5~10倍，SAS盘的3~5倍。时延比业界高端SAN存储快30%以上。通过P2P的扁平化IP网络架构，将大量的X86服务器上硬盘组成高度弹性、高性能、超大容量的块存储资源池,代替原有云资源池中数十套中高端存储设备和FC网络。华为分布式存储产品性能达到并超过传统的高端SAN存储，比业界传统使用的分布式文件系统性能上高出一个数量级。

浙江电信云资源池建设进程在整个电信集团一直保持领先，分布式存储系统的上线再次让领先优势扩大，在全集团具有示范意义。

客户收益

       构建弹性、可按需分配的高效存储资源池，存储资源统一管理，管理效率提升2倍以上，资源利用率提升50%+

       实现IO并行处理，现场实测底层最大IOPS达到130万，底层带宽达到120Gb/S，唯一通过客户性能测试的厂商

       通用开放的x86架构平台取代专用的存储设备，建设和扩容周期从60天以上缩短至两周，满足高速发展的业务需求

1

2

3

4

4.1下载本文