|
一、云存储 目前云计算、云存储、云备份等技术可谓是铺天盖地，其中不乏有很多是浑水摸鱼的，本来没有多少云的性质，只是打着云的旗号来炒作而已。 目前市场对一款产品是否是云，没有明显的界定。因为云本来就没有一个标准。 云的是怎么来的 国外在指代一堆设备的时候，一般使用Cluster这个词，而中文翻译一般是“簇”或者“集群”。云这个词来源已不可考，也许是某个人在讲授PPT的时候，顺口说了一句'The Servers in the cloud'的吧，这样Cloud这个词就诞生了。 对云的几种认识 目前人们对云的认识基本就有4种不同的观点：云即设备、云即集群、云即IT系统、云即服务
给云下个定义 那么云目前最主流的定义是啥？ 上面提到过，设备组成集群，集群搭上软件称为IT系统，IT系统用来服务，好了我们可以把之前的观点结合起来下个定义：
但是这个定义缺少最关键的东西，就是资源迅速灵活地部署和回收。所以云当前最主流的定义为： 云是一个智能IT系统，它是：
也就是
那么云应该具有如下性质：
也就是云其实是一种商业模式，如果认为只有底层使用了硬件集群和虚拟化技术的系统才是云这种观点是非常狭隘的。  谁催生了云 谁催生了云？当然是需求 传统IT的问题 互联网以及智能终端的普及，让信息得到了爆发性的增长，那么对IT基础架构（计算、存储、网络）来说，正在快速被饱和。 我们可以看看传统IT怎么运作的？比如运营商部门分析出网页游戏业务会有20%的增长，所以需要扩容，比如增加Web服务器、数据库服务器、存储系统的数量或容量，然后需要采购设备，遵循一系列的流程，这样周期非常的长，甚至慢于业务的变化周期。 但是另外一个部们的在线视频业务因为业绩不好，利用率不足60%。 当然最原始的想法是将在线视频业务的的40%余量分配给网游部门，不过会存在大量的技术风险。比如两种业务部署在同一个操作系统，会增加业务的粘度，不利于运维，然是如果把业务部署在不同的服务器上，更不利于运维。 加上现在数据中心中存在不同的协议、不同厂商的设备，如果靠手动来部署、管理和回收资源，效率低而且容易错，业务上线的速度也不快。 我们总结一下，传统的IT系统存在三个问题：
这就痛点。 云其实是商业模式 不过上面的说法只是云诞生的一部分理由，实际上最初的云，实际是一种商业模式，当商业模式与计算机技术结合之后，才产生了云这个代名词。这也是云没有外在的像技术一样严格的标准的原因。  系统架构变化 要解决之前提到的业务部署周期长，无法实现自动化，资源不能方便的回收和复用等，最容易想到的技术手段自然是虚拟化。 服务器虚拟化，即虚拟机系统，充分利用了资源，再加上Vmotion,DRS(Distrubted Resource Scheduler)等技术，极大的增加了部署灵活性和资源均衡性。 我们来看看部署了虚拟机以后对之前的问题带来的变化。
那么所谓虚拟化，其实就是在传统的数据中心上加上一个弹性层，这样整个数据中心就变成了软数据中心了。 如果还能做到部署回收自动化、可度量化、服务化、可运营的数据中心，则就是一个云数据中心了。 综上所述，云系统中重要的角色有：
纵观云发展的过程中，说不清到底是先有云这种商业模式还是先有云这种技术架构的，两者其实是相互催生、相辅相成。 回顾存储系统的技术发展过程。
 公有云和私有云 现在我们已经有了一个云化的数据中心了，那么可以按照数据中心的是对企业内部开放服务还是给任何人开放服务来分为私有云和共有云：
综上所述，云目前最能被广泛推进的地方就是新建数据中心，企业兴建私有云，运营商兴建混合云  云系统架构及组成 下图为云具体的架构：  分为如下几个层次
 那么出租数据中心其实可以在以下几个层次中进行：
实例说云 下面使用3Tera Applogic的例子来说一下IaaS层 3Tera的IaaS平台名为Applogic，是一不可以实现IaaS功能的软件虚拟化平台。我们可以看一下它的底层架构： 主要分为4大层次：
Applogic带来的革命是把复杂的底层硬件变得简单，通过拖拽对象来状态自己的基础架构，最终以适合某中Application运行的整体服务器&存储&网络来交付。  云的缺点 在看云的缺点之前先看一下云的优点：
存在的问题：
云之后的发展 云的本质 云本质是一种服务，而不是一种物质，正因为此，它必须基于物质才能显示功效，《易经》有云：“形而上者谓之道，形而下者谓之器”。所以下器者，谓之服务器 存储 部署管理软件；上道者，谓之“云”。所以云是一种道，是一种方式和方法，而不是某种设备，某个软件，当然云需要由硬件 软件来承载而已。 所以，云和速度性能没有直接关系。云本身不一定就是一个高速高冗余的东西，而是说底层硬件一般使用并行计算集群和存储集群，在这个基础上，云才能表现出更大的效能。 而且云也不是为了提速而生，它的主要目的是廉价高效的利用资源并降低硬件的应用成本和管理成本。 其实云早就存在了，只有近两年才被炒作起来，互联网服务器就是云服务，所以有人提出IT服务即云，Everything as a service。 其实在40年前，我们还是用集中分时计算，随后到了世纪相交的纪念，用户各自购买基础架构进行计算和存储，然后又逐渐回到了集中计算的时代，实际上这既不是进化，又不是退化，是“分久必合，合久必分。万物皆在轮回中不断发展，到一定程度就回到当初的形态，但是承载它的物质是连续不断的提升的。所轮回的只是其上的那层能量，谓之道。 Micro、Mini、Normal、Huge、Grid弹性数据中心 弹性核或者软数据中心：将若干刀片与高密度的磁盘柜以及微型交换机打包到一个或者几个机柜里面，再覆盖以弹性层，比如虚拟机管理系统以及分布式存储系统，将这样一个微型弹性软核心做为一个可提供IaaS服务的整体交付给用户。 或者再在这个软核上覆盖一层业务展现于管理层，直接交付到SaaS层。一柜或者数柜交付的弹性基础设施，可以称为Micro Cloud 二、数据容灾
容灾可以分为四个级别：
 概述 如果要充分保证数据的安全，只是在本地做备份是不够的，所以需要在远程建另一个系统，并包含当前生产系统的全部数据，这个系统须
那么备份和容灾有什么区别呢？生产系统就好比手机，备份就是把手机上的数据备份到电脑上，但是如果这个手机坏了呢？要恢复数据需要大量的时间。 那么容灾就是我们有两部手机，而且他们的数据是使用云实时同步的，所以可以无缝切换。 如果我们预算充足，可以使用一直两台手机，那还需要备份吗？当然需要，比如某个时刻，我们把手机里面的某个联系人给误删了，因为容灾的手机是实时同步的，很难说能通过另一部手机找回来。但是如果之前有备份过数据，完全可以通过之前的备份进行恢复。 下面继续谈容灾。对于一个企业IT生产系统，主要有4个组件：
下面将对这四大组件的容灾进行讲解 生产资料容灾 生产资源容灾指的就是对原始数据进行容灾。这最重要的，因为没有生产资料一切等于从头再来。 要设计这样一套生产资料容灾，需要注意的是
如下为相应的拓扑：  主备站点都有相同的生产工具，使用网络相连。可以通过两种方式来进行同步：
通过前端网络同步 
那么到底选择专线还是Internet呢？专线可以保证数据同步的实时性，但是不适合大数量的传输。如果实时性要求不高，而且数据量大的时候，可以将主备站点接入100Mbps的Internet。 可以看出这种方式经过了前端网络，所以必须在每台需要备份的服务器上安装软件进行同步，这种软件可以监视目录中的数据变化，然后与远端的软件进行通信，写入相同的文件目录中。 这种方式的同步一般都是文件级的同步，对底层卷的数据块变化不做同步。 案例：DB2数据的HADR组件容灾 DB2数据库利用主备上的数据库软件模块（HADR）来实现两端的数据同步。而且同步的是不卷上的原始数据，而是对数据操作的描述，也就是日志。这样的好处是，不需要传输数据，备份机收到日志以后，在备机的磁盘上重做操作即可。 HADR:High Availability Disaster Recovery，是数据库级别的高可用性数据复制机制。需要两台数据库服务器：primary , standby
通过后端网络实现同步 通过后端网络进行同步，数据不会流经前端网络，而全部通过后端网络传输到备份的存储上。所以需要将主站点和备站点的后端网络设施连接起来。要么直接拉光纤，要么用专线。 如果用专线的话，需要增加额外的协议转换设备，现在电信部门的光纤专线一般为SDH传输方式，接入到用户端的时候，一般将信号调制成E1、OC3等编码方式。 上图中，FC协议，经过FCIP网关，变成基于以太网的IP协议，（FC over IP over ETH）。经过E1/以太网转换器，承载到了E1协议上，然后多路E1信号汇聚到光端机，通过一条或者多条光纤，传输给电信部门的SDH交换设施进行传输。 这样我们就将主站点和备站点的后端网络打通了，此时主服务器就可以访问到备份的磁盘阵列，也就是说主站点的服务器可以同时操作本地磁盘和备站点的磁盘阵列了。 我们来看一下这种方式的路径：
数据到了远端SAN不需要再经过服务器，因为有了对方存储设备的直接访问权。但是整个过程中，仍然至少需要一台服务器，服务器上需要安装一个软件，可以将数据从本地卷A提取出来，然后直接通过SAN网络写到位于备份站点的卷B上。 但是试想一下，如果数据直接在内存中生成的，那么同时在A和B上各写一份，速度岂不是更快，这种方式又叫“卷镜像”，因为可以时时刻刻保持两个卷完全相同，它能保证数据同步的实时性，但是不适合大规模远距离的数据同步。 同时还需要注意的是，卷镜像的的同步软件工作在卷这一层，可以感知数据块的变化，而不是文件的变化。缺点在于对网络速度要求更高，所以成本也更高。 通过数据存储设备实现同步 之前讲的通过前端网络和通过后端网络的方式，都使用了一个泵来提供动力。而如果将数据同步软件安装在存储设备上，岂不是更省事。而且这样彻底解放了服务器，所有工作都由磁盘阵列完成。 这种方式的同步，不会识别卷上的文件系统，所以同步的是块。而且要求主和备的存储设备型号一致。因为不同厂家的产品无法实现直接同步。 这种方法的缺点是不能保证数据对应用程序的可用性。 因为存储设备与应用程序之间还有操作系统这一层，操作系统也有自己的缓存机制，所有有可能造成数据的不一致性。 总结：
容灾中数据的同步复制和异步复制 同步复制 下图是基于存储设备的自主同步环境。
异步复制 相对于同步复制，两边的步调不需要一致，要保证重要的事情先做完，所以会存在一定的数据不一致。
生产者容灾——应用程序容灾 之前讲的都是生产资料的容灾，也就是整个系统最重要的数据的容灾。而对于生产者，无疑就是服务器上的应用程序，如果主发生故障，需要在备站点重新运行这些应用程序。最直观的想法是，在备站点预备应用程序的安装文件，一定主出现故障，在备上配置这些应用程序，但是实际上应用程序安装和配置需要大量的时间。所以可以将备份站点预装应用程序，但是不工作，这样就可保证同一时刻整个IT系统只有一个站点的生产者处理一份数据 既要求处理同一份数据，又要求发生事故的时候，备份站点的生产者立即启动，要做到这点，需要让备份站点的应用程序感知到主站点的应用程序状态，一旦发现故障，立即启动开始生产。 在之前的章节中，我们说到了高可用群集，在容灾系统领域，群集的范围扩大到了异地，主备可能相隔很远，交换运行状态的数据量很小，最好使用专线，这样可以很好的保证QoS。 传统的HA软件是使用共享存储的方式来作用的，即在HA系统中，共享一份物理存储，不管谁来操作这份数据，最终只有一份，而且是一致，有上下文逻辑关系的。 所以HA软件是基于资源切换的，把组件看作是资源，比如应用、IP地址、存储卷等。 当故障时，
这样应用系统可以访问共享卷，客户端也可以使用原来的IP地址来访问服务器，这样生产就可以继续下去。 但是在异地容灾系统中，主备站点各有一份数据，所以必须保证数据的同步。这也是为什么两个站点同时只有一个在工作，这样的话才能以一边数据为准，另一边与之同步。 本地容灾 本地HA系统中，多个节点如果共同拥有同一个卷，但是同一时刻只有一个节点能挂载它，这种模式叫共享存储模式 与之对应的是Share-Nothing模式，每个节点都有自己独占的存储卷，怎么进行数据共享呢？可以通过同步复制技术同步到所有节点上。若某节点发生故障，这个节点对应的备份节点启动应用程序。因为之前的数据已经同步过了，所以数据一定是一致的。 在Share-Nothing模式下，不存在任何的接管问题，所以客户端需要感知服务端群集这种切换动作，通过客户端进行配置的切换即可。 可以对共享存储和Share-Nothing两种存储模式进行对比。 共享存储Share-Nothing数据本身是否容灾×√软硬件成本高低前端网络资源消耗低高管理难度高低维护数据是否需要停机√×实现的复杂度高低是否需要第三方软件√×故障因素数量3个2个
异地容灾 如果主站点和备站点不在同一个机房中，这样备份应用程序需要跨越很远的距离来与主程序交互状态。只是说这种交互包很小，不需要担心延时的问题。 IP切换 在异地容灾系统，主服务器和备服务器不大可能在同一个广播域，所以需要通过网关来转发IP包，正因为此不能用资源切换的方式来切换IP地址。 如果想故障后，客户端继续使用原来的IP地址连接备份服务器，那么可以在路由上做文章。动态修改路由器上的路由表，将IP包路由到备份站点而不是主站点。如果利用域名来访问服务器，那么可以直接在DNS设备上修改IP指向记录来实现。 卷切换 异地容灾系统在主站点和备站点各有卷，两个卷通过前端或者后端网络进行同步。 如果备的HA软件检测到主站点通信失败，通过某种方式，断开同步关系（若不断开，卷会被锁定而不可访问）。然后就是重新挂载备站点的卷 此时同步引擎可以是运行在存储设备上，也可以由HA来执行。
异地容灾的应用切换 应用，也就是生产者的切换，是所有HA容灾系统在故障发生后所执行的最后一步。与共享存储式的HA容灾一样，异地容灾的应用切换，是有备机的HA软件来执行脚本，或者调用相应的接口来启动备份机的应用的。 三、数据保护和备份技术 从底层来分，数据保护可以分为文件级保护和块级保护。 文件级备份
此时备份软件只能感知到文件这一层。 我们知道一般来说，文件在原来的介质上，可以是不连续存放的，通过文件系统来管理和访问。当备份到新的介质上以后，文件完全可以连续存放。正因为如此，没有必要备份元数据，因为利用新介质进行恢复的时候，反正会重构文件系统。 块级备份
这样好处是不通过调用文件系统接口，速度更快，缺点的是备份的时候会把所有的块复制一遍，但是实际上很多扇区的数据是不对应真实文件的，也就是会备份很多僵尸扇区。而且备份之后，原来不连续的文件一样是不连续的文件，有很多的碎片。 高级数据保护远程文件复制
远程卷镜像 这是基于块的远程备份。与远程文件复制不同的地方在于，是把块数据备份到异地站点。又可以分为同步和异步复制。
基于块的备份措施，一般都是在底层设备上进行，不耗费主机资源。 快照 远程镜像确实是对生产数据一种非常好的保护，但是需要镜像卷一直在线，主卷有写IO，那么镜像卷也需要有写IO。 如果想对镜像卷进行备份，需要将停止主卷的读写，然后将两个卷的镜像关系分离。所以当恢复主卷的IO的时候，镜像卷不会再被读写。然后才可以备份镜像卷的数据。 这样会存在一个问题，主卷上还继续有IO，将会导致数据与备份的镜像不一致。所以主卷上所有的写IO动作，会以位图bitmap方式记录下来，bitmap上的每个位表示卷上的一个块，0表示未写入，1表示已写入，所以当拆分镜像以后，被写入了数据，程序将bitmap文件对应位从0变为1。备份完成以后，再做数据同步即可。 可以看出上述过程比较的繁琐，而且需要占用一块和主卷一样大小的镜像卷。 快照技术就是为了解决这种问题，其基本思想是抓取某一时间点磁盘卷上的所有数据。 快照分为：基于文件系统的快照和基于物理卷的快照 下面介绍一下快照的底层原理。 基于文件系统的快照
文件系统
写入新数据
删除数据
可以看出删除数据实际上不会抹掉实际的数据。 ** 所以，最重要的不是数据，而是文件——簇号映射链和位图等元数据。** 也就是说我们要做备份，只需要把某时刻的文件系统中的映射图表保存下来。但是必须保证卷上的数据不被IO写入了，同时又要不应用还不能中断。既然原来的空间不能再写了，我们可以写到其他的空闲区域。
下图为生成两个快照之后系统处理流程。 到这一步，看上去挺完美，实际上存在一个问题：如果元数据特别大怎么办？对于海量庞大的文件系统，元数据量可能到GB级别。如果复制的话，时间上仍然太多。 我们可以回头想想，实际上元数据可以看做指针，指向具体存储的位置。我们复制到元数据，相当于复制了一堆指针。现在元数据太多了，我们能不能把这个元数据链的指针给复制了？当然可以，元数据有个根入口块，或者称为Super Block，这个块是固定不变的，里面存放有指向下一级元数据链块的指针。 那么操作系统每次载入元数据的时候，都需要从这个地址读入Super Block，从而一层一层的遍历。 下图为只复制Super Block以后的RoFW模式： 基于物理卷的快照 基于物理卷的快照比文件系统快照要简单得多。因为LUN一般在底层磁盘上是恒定的，不像文件系统一样可以随机细粒度的分布。所以可以认为LUN的元数据就是在底层磁盘的起始和结束地址 这样在快照的时候，需要复制的元数据就更少了，但是完成了以后，需要按照一定粒度来做CoFW或者RoFW，还需要记录更多数据映射指针，就比较难受了。 对于实现了块级虚拟化的系统如NetApp,XIV,3PAR等，它们的LUN在底层位置是不固定的，LUN就相当于一个文件，存在元数据链来进行映射管理的维护，所以这些系统实现快照的原理与文件系统快照类似。 基于物理卷的快照，相当于给物理卷增加了“卷扇区映射管理系统”。在底层卷实现快照，可以减轻文件系统的负担。 卷扇区方都是用LBA来编号的，实现快照的时候，程序首先保留一张初始LBA表，每当有新的写入请求的时候，重定向到另一个地方，并在初始的LBA表中做好记录。比如
值得说明的是，文件系统无法感知重定向，文件系统在它的映射图里面还是记录了原始的LBA地址。 此时如果来了新的写IO，有两种方式一种是Write Redirect 一种是Copy on Write 所谓Write Redirect就是将文件系统的读写请求，重定向到卷B，这样每次IO其实都会查找快照映射表，降低了性能。所以引入了Copy on Write 所谓Copy on write，就是当写请求来的时候，先把原来的扇区的数据复制一份到空闲卷，然后将新数据写入原卷。不过这种复制操作只发生在原卷某个或者快照之后从未更新过的块上面，若是某个块在快照之后更新过了，说明之前的数据已经转移走了，可以放心的覆盖。 所以Copy on Write实际上是让旧数据先占着位置，等新数据来了以后先把原来的数据复制走，再更新，而且一旦更新了一次，可以直接覆盖。 带来的好处是 ，原卷上的数据随时是最新的状态，每个IO可以直接访问原卷的地址，而不需要遍历映射表。 RoFW 方式与CoFW方式比较 不管是RoFW还是CoFW,只要上层向快照后没有更新过的数据块进行写，都需要占用一个新的块。所以如果将所有扇区块都更新了，新卷的容量和原来的容量应该一样大，但是通常不会覆盖百分之百，所以只要预设原容量的30%即可。 IO资源消耗：
由于只有首次覆盖才会Copy或者Redirect，那么如何区分是否是首次覆盖呢？可以使用记录表（文件级快照）或者位图（卷快照）来记录每个块是否被覆盖过。 对于读IO，
综合来说，RoFW比较吃计算资源，而CoFW比较耗费IO资源。 我们知道其实一般来说读比写多，当覆盖第二次以后
尤其在LUN卷级快照下，原本卷在底层磁盘分布式是定死的，寻址非常迅速。但是RoFW引入了，LUN的块随机定向到其他的空间的，所以需要记录新的指针链，而且被写出的块不是连续排列的。对性能影响非常明显的。 绝大多数的厂商使用的还是CoFW，但是一些本来就使用LUN随机分块分布模式的存储系统比如XIV,NetApp等，都使用RoFW，因为原本其LUN的元数据链就很复杂，而且原来就是随机分布的，RoFW的后遗症对它们反而是正常的。 快照的意义 快照所保存下来的卷数据，相当于一次意外掉电之后卷上的数据。怎么理解? 上层应用和文件系统都有缓存，文件系统缓存的是文件系统的元数据和文件的实体数据。每隔一段时间（Linux一般是30s）批量Flush到磁盘上。而且不是只做一次IO，有可能会对磁盘做多次IO。如果快照生成的时间恰恰在这连续的IO之间，那么此时卷上的数据实际上有可能不一致。 文件系统的机制是先写入数据到磁盘，元数据保存在缓存里面，最后再写元数据。因为如果先写元数据，突然断电了，那么元数据对应的僵尸扇区的数据会被认为是文件的，显然后果不堪设想。
那么为什么还要用快照呢？
但是快照会存在不一致的问题，如何解决？ 既然快照无异于一次磁盘掉电，那么利用快照恢复数据之后，文件系统可以进行一致性检查，数据库也会利用日志来使数据文件处于一致。 另外，现在主流的快照解决方案是在主机上安装一个代理，执行快照前，先通知文件系统将缓存中的数据全部Flush到磁盘，然后立即生成快照。
卷Clone 快照类似于某时刻的影子，而克隆则是某时刻的实体。每时刻生成了一份可写的快照，就叫对卷某时刻的一份Clone。然后这份Clone内容每被修改的部分是与源卷共享的，所以源卷没了，则Clone就没了，所以叫虚拟Clone 如果把数据复制出来，生成一个独立的卷，则就叫Split Clone，也就是可以得到实Clone。 卷Clone最大的好处在于可以瞬间生成针对某个卷可写的镜像，而不管卷的数据量有多大。 数据备份系统的基本要件
下面重点介绍一下备份目的、备份通路、备份引擎 备份目的 备份到本地磁盘 备份目的地是在本地的磁盘，则只需要将数据备份到本地磁盘的另外分区中或者目录中。 这样不需要网络，缺点是对备份对象自己的性能影响大。还会对其他的IO密集型程序造成影响。 这种方式一般用于不关键的应用和非IO密集型应用。比如E-mail，对转发实时性要求不高。 备份到SAN上的磁盘 备份到SAN上的磁盘，就是将需要备份的数据，从本次磁盘读入内存，再写入HBA卡缓冲区，然后再通过线缆传送到磁盘阵列上。
备份到NAS目录 备份到NAS目录就是将数据备份到远程共享目录中。比如window中常用的文件夹共享。因为数据一般是通过以太网进行传递的，占用了前端的网络带宽，但是相对廉价，不需要部署SAN 备份到磁带库 现在出现一种虚拟磁带库，即用磁盘来模拟磁带，对主机来说看到的是一台磁带库，实际上是一台磁盘阵列，主机照样使用磁带库一样来使用虚拟磁带库。要做到这点，就必须在磁盘阵列的控制器上做虚拟化操作，也就是实现协议转换器的作用。 可以带来了的好处是：
信息生命周期管理 将使用不频繁的数据移动到低速、低成本的设备上。比如只给视频应用分配20GB的空间，但是报告有500GB的空间，剩下的空间是在在磁带库上。 分级存储
备份通路 本地备份 数据流向：本地磁盘——总线——磁盘控制器——总线——内存——总线——磁盘控制器——总线——本地磁盘 也即数据从本地磁盘出发，经过本地的总线 和内存，经过CPU少量控制逻辑代码之后，流回本地磁盘。 通过前端网络备份 经过前端网络备份的数据流向是： 本地磁盘——总线——磁盘控制器——总线——内存——总线——以太网卡——网线——以太网——网线——目标计算机的网卡——总线——内存——总线——目标计算机的磁盘。 数据从本地磁盘出发，流经本地总线和内存，然后流到本地网卡，通过网络传送到目标计算机磁盘。
通过后端网络备份 通过后端网络备份的数据流向是： 本地磁盘——总线——控制器——总线——内存——总线——后端HBA卡——线缆——后端交换设备——线缆——备份目的的后端网卡——总线——内存——磁盘 LAN Free备份 备份的时候不经过LAN，也就是不流经前端网络，也叫Frontend Free。这样的好处是不耗费前端网络的带宽，对客户终端接受服务器的数据不影响。。 因为前端网络一般是是慢速网络 ，资源非常珍贵。无论是本地、还是网络，都需要待备份的服务器付出代价，即需要读取备份源数据到自身的内存，然后从内存写入备份的目的地。对主机CPU、内存都有浪费。 能否不消耗服务器的性能呢？可以，使用Server Free备份。 Server Free备份 Server Free备份：备份的时候，数据不用流经服务器的总线和内存，消耗极少，甚至不消耗主机资源。 备份源和备份目标都不会在服务器上，因为如果在服务器上，数据从磁盘读出，要流将总线，然后到内存，这就不是Server Free 那怎么做呢？
备份策略
备份服务器 备份引擎以什么形式体现呢？当然是运行在主机上的程序，所以需要一台计算机来做引擎的执行者。 那么备份服务器的备份策略和规则，怎么传给整个数据备份系统中的服务器？通过以太网，因为以太网扩展性好，适合节点间通信。相对于以太网，SAN更适合传送大量的数据。所以常用前端网络来连接待备份的服务器和备份服务器，因为备份策略的数据包不多。 备份服务器如何与每个待备份的服务器建立通话？怎么通话？规则怎么定？需要待备份服务器上运行一个代理程序，专门解释备份服务器发来的命令，根据命令作出动作。 这个运行在待备份服务器上的程序，就叫备份代理，监听端口，接收备份服务器发来的命令。 介质服务器 若数据备份系统中有一台SCSI磁带机，且多台主机想备份到这台磁带机上。而SCSI磁带机只能同时接到一台主机上。 那么怎么办呢？可以引入一台专门的计算机，只能由这台计算机来操作磁带机。 需要备份的计算机通过以太网将数据发给这台掌管磁带机的计算机，然后写给磁带机。 这样磁带机成为了公用设备，而在整个系统中，只有一台计算机能掌管备份目标，它就类似于一个代理，代理其他服务器执行备份。我们把它称为介质服务器 还有一个问题，如果有多台服务器向介质服务器发出请求，怎么办?当然需要一个协调员，也就是备份服务器，它可以指挥安装在待备份服务器的代理，让每台服务器按照顺序有条理的使用介质服务器提供的备份介质进行备份。 三种备份方式 完全备份 不管文件多大，只要要备份，都需要将文件都备份下来。 差量备份 差量备份：只备份从上次完全备份以来发生变化的数据。 差量备份要求必须做一次完全备份，作为差量的基准点 增量备份 只备份从上次备份以来这份文件中变化过的数据。** 上次备份**，不管是全备、差备，还是增量备份。 对于数据库的备份，备份软件想知道每个数据文件的变化是不可能的，因为数据库文件内部格式非常复杂，只有自己才能分析和检测出来。所以数据库管理软件有自己的备份工具。第三方备份软件只能调用数据库软件自身提供的命令。 四、DAS , SAN和NAS NASLUN只是一个卷设备，对主机而言就是一块硬盘，我们的操作系统集成了文件系统的功能，可以用来管理卷。而 NAS就是把文件系统从主机迁移到磁盘阵列上，自己来管理。使用者只需要通过网络告诉这个文件系统需要存取什么文件而不需要向NAS传递LBA地址。 那么NAS与SAN的区别是什么？ SAN是网络上的磁盘，NAS是网络上的文件系统。
另外， FTP服务器属于NAS吗？不属于，为什么？ 我们知道网络文件系统与本地文件系统最大的区别是传输方式从主板的导线变成了以太网络，也就是传输的距离可以更快了。但是FTP实际上必须把文件传输到本地的某个目录才能执行，而网络文件系统不需要将数据复制到本地再进行访问，可以进行挂载。 NAS与SAN之争谁更快 NAS主要实现虚拟目录层与文件系统层的通信，使用的是“以太网 TCP/IP”，为了处理TCP/IP和以太网逻辑，增加了不少的CPU指令，同时使用的是以太网等低速介质。 而FC SAN中，FC逻辑有很大一部分由HBA卡完成，同时FC协议的速度比以太网更快，所以整体来说FC SAN肯定更快。 但是在大量随机小块IO的场景下，因为NAS系统对并发IO进行了优化，而且文件系统逻辑由专门的设备处理，所以性能可能会比SAN更高。 既然这样，为什么还需要使用NAS呢？因为
所以单纯的讨论SAN好还是NAS好是没有意义的，我们更需要的是根据场景、成本等要素来决定到底使用NAS还是SAN。 我们可以把目前的应用分为两种：IO密集与CPU密集
对于高并发随机小块IO，或者共享访问文件的环境，因为NAS做了很多的优化，此时应该优选NAS。而对于大块顺序IO密集的环境，NAS比SAN慢，所以优选SAN。 与SAN和与NAS设备通信的过程对主机而言，如果与SAN通信，必须通过文件系统。当应用程序发出指令后，文件系统会计算LBA地址，然后通过FC网络告诉SAN。SAN取出数据，通过FC网络传送给主机，然后放入程序的缓冲区。 那与NAS设备通信呢？程序只需要告诉NAS设备路径 文件即可，也就是说通过操作系统的虚拟目录与NAS进行对话，通过TCP/IP 以太网进行传输，后面的过程就都在NAS设备内部了，它会查找要取的文件的扇区位置，存储数据。 其实NAS设备还可以进行拆分，它可以把硬盘拆分出去，只是做为一个专门处理文件逻辑的设备而存在，这就是NAS网关 DAS、NAS、SAN
DAS（仅供自己使用）到SAN（出租仓库给其他的租户），到NAS(集中式理货服务外包) SAN是一种网络，而不是某种设备。只要是专门向服务器传输数据的网络就可以称为SAN。 NAS设备通过以太网向主机提供文件级别的数据访问，以太网络就是SAN。 习惯性的将FC SAN架构称为SAN NetApp的NAS NetApp的NAS极大的借鉴了数据库管理系统的设计，本小节主要讲解一下NetApp的NAS的基本思想。 利用了数据库管理系统的设计 我们知道数据库管理系统是这样记录日志的，在某个时刻，数据库管理系统接收到应用程序的SQL更新语句，首先将数据修改前的状态以日志的形式保留在内存的日志缓存区，然后覆写原来的数据。 因为日志缓存区是内存的一部分，所以如果掉电则数据丢失，所以每隔一段时间或者说程序进行提交事务时，管理系统会把日志推到磁盘中。同理，也会把缓存中更新过的数据块写入磁盘。 只有当日志确实写入到硬盘上的日志文件中的时候，才会对上层应用返回执行成功。 具体过程可以参见数据库（五），事务。 NetApp借鉴了这种设计思想，它会将文件系统中的写入请求作为操作日志写入到NVRAM中保存。
为什么要使用NVRAM而不像数据库一样使用文件来保存日志的呢？ 对于数据库系统来说，先将日志写入到内存中日志缓冲区，再在触发条件下将日志写入磁盘上的文件。一旦意外掉电，内存中的日志没有来得及保存到硬盘就丢失，数据库再次启动的时候，会提取硬盘上的日志，对于没有提交的操作进行回滚。这样就保证了数据的一致性。 不过如果应用程序频繁提交，日志缓冲区的日志会频繁的写入到磁盘上，这时日志缓存就起不了什么作用了。 对数据库来说，上层的每个业务一般都算是一个交易，在尚未完成的时候，程序不会发送提交指令给数据库系统的，所以频繁提交的频率不高。 而文件系统则不然，上层应用向文件系统写入数据而言，每次请求都是完整的交易。也就是说提交会非常频繁。如果将操作日志写入磁盘，开销大，所以利用了带电池保护的RAM内存（NVRAM）。只要成功写入了RAM，就可以立即通知上层写入成功。 一定要搞清楚日志和数据缓存的区别。
WAFL的做法是用RAM来保存日志，可以一次接收到上千条写请求，而且可以直接返回成功。等到RAM半满，由WAFL一次性批量连续写入硬盘，保证高效率。 WAFL从不覆写数据
WAFL不会覆盖掉对应区块中原来的数据，而是寻找空闲块来存放被更改的块。也就是说WAFL写入的数据都会到空闲块中，而不是覆盖旧块。另外，在Checkpoint没有发生或者数据没有Flush完全之前，WAFL从来不会写入任何元数据到磁盘。 这样可以保证CheckPoint没发生之前，磁盘上的元数据对应的实际数据仍为上一个CheckPoint的状态。如果此时断电，就算新数据写入了，但是元数据没有写入，所以磁盘上的元数据仍指向旧块，数据就像没有变化，所以不用执行文件系统检查等工作。 当CheckPoint触发时，先写入数据，最后再写元数据，然后新元数据指针指向方才写入的新数据块。对应的旧数据块变为空闲块。（此时块中仍然有数据，但是没有任何指针指向它） IP SAN以太网的可寻址容量大，比IP都大，而且地址是定长的，使用专用的电路完成交换，还可以使用光纤进行传输。最重要的一点是以太网非常的廉价。 但进入以太网有这么多优点，现在FC SAN还是应用广泛，这是因为以太网与FC相比，以太网是不可靠的网络，不是端到端的协议，必须依靠上层协议。而且开销也比较大。 IP SAN TCP/IP在速度和性能上无法与FC相比，但是它最大的优点在于扩展性，SCSI都能嫁接到FC上，当然也可以与TCP/IP结合。这种新的协议系统叫ISCSI（Internet Small Computer System Interace ）。 这种协议的优点很明显，只要IP可达，两个节点就可以通过ISCSI通信。所以扩展性非常强。
当然IP SAN不一定用以太网作为链路层，可以用任何支持IP 的链路层，如 ATM 、PPP 、 HDLC 甚至是FC 同样用TCP/IP来进行传输，NAS与IP SAN有什么区别呢？ NAS传输的是文件系统语言。ISCSI传输是SCSI指令语言。所以IP SAN本质是SAN提供的是块存储 IP SAN相对于FC SAN最大的优势在于：
五、Fibre Channnel协议 SAN的概念，SAN首先是个网络，而不是存储设备。这个网络是专门来给主机连接存储设备用的。 我们知道按照SCSI总线16个节点的限制，不可能接入很多的磁盘，要扩大SAN的规模，只使用SCSI总线是不行的，所以必须找到一种可寻址容量大、稳定性强、速度块、传输距离远的网络结构。FC网络就应运而生。 FC网络Fibre Channnel也就是网状通道，FC协议从1988年出现，最开始作为高速骨干网技术。 任何互联系统都逃不过OSI模型，所以我们可以用OSI来将FC协议进行断层分析。 物理层 首先有较高的速度：1Gb/s,2Gb/s,4Gb/s，8Gb/s到16Gbps 为了实现远距离传输，传输介质起码是光纤 链路层 字符编码及FC帧结构 FC协议的帧头有24字节，比以太网帧头（14字节）还要长。 比如下图为以太网的报文格式。 为什么FC协议需要这么长的帧头呢？因为24字节的帧头不但包含了寻址功能，还包含了传输功能保障。也就是说网络层和传输层的逻辑都用这24字节来传输。 这点就与TCP/IP 以太网不同，以太网基本上没有传输功能保证功能，主要需要靠TCP来进行端到端的传输保障。 我们可以对比一下TCP/IP和FC协议的开销： 基于以太网的TCP/IP网络，开销为：
而FC协议就24字节，所以开销比TCP/IP的要小。 网络层FC网络中的节点要通信，无非也就是连、找、发三大要素。
从这个方面基本上就可以了解FC各节点交互的流程了。 连：拓扑 与以太网类似，FC也有两种拓扑：FC-AL和Fabric
仲裁环是应该 由所有设备串联而成的闭合环路，每个接口上都有一套旁路电路（Bypass Circuit）,一旦检测到本地设备故障，就会自动将这个接口短路。 一跳一跳的传输，而且任何时候只能按照一个方向向下游传输。
相对于仲裁环路来说转发效率提升了很多，联入矩阵所有节点可以同时进行点对点通信，加上包交换所带来的并发和资源充分利用，可使得交换架构获得的总带宽为所有端口带宽之和。 而AL架构下，不管接入的节点有多少，带宽为恒定，即共享环路带宽。 下图为交换矩阵的示意图。 FC终端设备接入矩阵端点，一个设备发给另一个设备数据帧被交换矩阵收到后，矩阵会拨动交叉处的开关，连通电路，传输数据。所以可以把交换矩阵是一个大的电路开关矩阵，根据通信的源和目的决定波动哪些开关。 FC交换拓扑寻址容量是2的24次方个地址，比以太网理论值（2的48次方）少，但是对于专用的存储网足够。 找：编址 任何网络都需要寻址机制，所以需要对FC网络的每个设备定义一个唯一的标识。
以太网交换设备的端口不需要有MAC地址，而FC交换机却需要每个端口都有自己的WWPN。这是因为FC要做的工作比以太网交换机多，许多FC的逻辑都集成在了FC交换机。 需要处理到FC协议的最上层。而以太网相对简单，因为上层逻辑都被交给TCP/IP这样的上层协议来实现了。 WWPN：长度是64位，比MAC地址多16位。长度太长，速度低，所以在WWPN上映射一层寻址机制，分配一个Fabric ID，嵌入链路帧里面来做路由 这样WWPN被映射到了Fabric ID，一个24位的Fabric ID又被分为Domain ID、Area ID、Port ID三个亚寻址单元
发：地址映射过程 如下的讲解主要是针对Fabric 交换架构网络。 既然要把WWPN映射到Fabric ID上，就一定要有映射机制，那么每个端口如何获得Fabric ID的呢？过程比较类似于RARP协议。 当一个端口接到FC网络的时候，会向注册服务器发送一个注册申请，然后这个注册服务器会返回给它动态分配一个Fabric ID。当然此时注册服务器会记录这个映射关系。 此后这个接口的帧不会携带WWPN，而是携带其被分配的ID作为源地址。这点就与以太网不同，我们知道 以太网既携带MAC又携带IP，所以在效率上打了折扣。 发：同步其他节点信息 不过还有一个问题，一个端口要与另一个端口通信，那么怎么知道要通信目标的Fabric ID是多少呢？ 每个节点获得自己的Fabric ID之后，还会进行名称注册。同样也是向名称服务器发送注册帧，主动告知自己的Fabric ID等信息。然后名称服务器其他节点的信息返回给它。这样就知道了其他节点地址呢。 如果FC网络比较大，则可能不只一台FC交换机。也就是说有若干FC交换机互联。与IP网络不同的是，FC网络不需要太多的人工介入，它们会自动协商自己的Domain ID（可以回过去看看Fabric ID的结构），选举出主交换机，由主交换机来为其他的交换机分配Domain ID。交换机之间会运行OSPF等路由协议，这样可以交互节点信息，寻址各个节点。 现在我们可以与IP网络对比一下，IP网络需要很强的人为介入性，需要人来配置节点的IP地址、路由信息等，而FC网络则可以自动分配和管理地址。最根本原因是因为FC协议一开始设计就是为了高速、高效的网络，而不是给Internet使用的。所以自动分配地址当然适合。 发：与目标通信 此时每个节点已经获得了Fabric ID了，同时还从名称服务器得知网络上其他节点的ID，万事俱备，完全可以与其他节点进行通信了。
FC网络中还有一中FC Control Service，如果节点向这个服务进行注册了以后，一旦网络状态有变动，将会把最新的信息同步到这些节点。 最后一点 上面提到的名称服务器、注册服务器其实一般都是运行在交换机内部的，而不是物理上的服务器。 传输层FC协议的传输层的作用与TCP相似，也也进行Segment以及通过端口号区分上层应用。
FC适配器要构建一个完整的FC网络，除了需要FC交换机，还需要FC适配器(FC HBA,Host Bus Adapter)
下图是用来接入FC网络的各种线缆，有SC光纤，DB9铜线和RJ45/47线缆。可以看出FC不一定是光纤 FC适配器有自己的CPU、RAM、ROM。是一个嵌入式设备。与RAID卡类似，只是不像RAID卡需要那么多的RAM来做数据缓存。 SCSI迁移到FC如何迁移 在上面一章我们把FC协议进行了简单的介绍，现在是时候把SCSI迁移到FC上了。 回顾一下，为什么要这么做，因为SCSI总线只能接16个节点，不利于扩展，同时传输的距离有限，而且不够高效等。所以我们可以在主机与后端存储之间使用FC协议，把基于并行SCSI总线的存储网络架构迁移到FC的网络架构。 迁移的过程中存在一个问题，我们知道FC协议并没有定义SCSI指令集这样面向磁盘存储数据的通用语言。那怎么解决这个问题呢？ 在【大话存储】学习笔记（13章），协议融合中提到了协议融合，此时FC协议与SCSI协议有重叠，但是FC协议在某些方面可以做得更好，所以可以将SCSI语言承载于FC协议进行传送。 将连接主机和磁盘阵列的通路从并行的SCSI总线替换为串行传输的FC通路。但是盘阵后端连接磁盘的接口还是SAS接口。 这样单台盘阵所能接入的磁盘容量没有提升，但是前端的性能提升了，因为使用FC协议，可以更为的高速。 好处 引入FC之后，带来的好处为
这样就实现了多台主机共享一个盘阵，提升了盘阵的利用率。
多路径访问目标如果盘阵有两个控制器，每个主机上都有两块FC适配卡，它们都连接到了FC交换机。 这样会存在一个问题，因为主机有两块HBA卡，而每块HBA可以识别两块LUN，所以整个主机会识别出4块磁盘，这就有问题了，因为这样磁盘就有重复了，造成了混乱。 那么你可能会说，为啥要两块FC HBA卡呢？因为一块HBA有单点故障，如果使用两块HBA卡，一旦一块HBA卡出现了故障，另一块卡依然可以维持主机到盘阵的通路。 那多路径的问题怎么解决：可以在操作系统中安装多路径软件，它可以识别FC提交上来的LUN，向操作系统提交单份LUN。这个软件还有个作用，如果某个控制器发生故障，通过这个软件立即重定向到另一个控制器。 参考 |
|
|
