存储入门知识大全（存储技术详解）

一、云存储

目前云计算、云存储、云备份等技术可谓是铺天盖地，其中不乏有很多是浑水摸鱼的，本来没有多少云的性质，只是打着云的旗号来炒作而已。

目前市场对一款产品是否是云，没有明显的界定。因为云本来就没有一个标准。

云的是怎么来的

国外在指代一堆设备的时候，一般使用Cluster这个词，而中文翻译一般是“簇”或者“集群”。云这个词来源已不可考，也许是某个人在讲授PPT的时候，顺口说了一句"The Servers in the cloud"的吧，这样Cloud这个词就诞生了。

对云的几种认识

目前人们对云的认识基本就有4种不同的观点：云即设备、云即集群、云即IT系统、云即服务

• 云即设备：
• 这是最原始的观点，也就是所谓的云只是指代一堆设备，因为没有设备的支撑，哪来的云。
• 云即集群：
• 光有设备还不行，还需要这堆设备有机的联系起来，相互协同，对外呈现为一个集群，这是在“云即设备”上的一次发展。
• 云即IT系统：
• 上面说到的集群，也只是一堆服务器放在一起，可以协作，若要进一步发展，需要加上软件作为灵魂，比如某企业的IT系统。
• 云即服务：
• IT系统一般是用来支撑企业的业务的，但是我们能不能通过他来盈利呢？这就涉及到商业模式上面了。主要有如下几种模式：
• 直接卖了：
• 如果像卖房子一样，受众很小，因为需要购买一整套IT系统的人很少。
• 租出去：
• 这就如同租房子一样，受众相对于卖房子大很多。但是盈利慢
• 利用IT系统来运营某种业务，用来赚钱：
• 这种方式受众更大，像邮箱、网页、博客，几乎全民都是客户，所以盈利面很大。这样看来，能提供某种形式IT服务的一整套IT系统都是云。从这个角度，所有的互联网运营商，比如各大网站，都是云运营商。

给云下个定义

那么云目前最主流的定义是啥？

上面提到过，设备组成集群，集群搭上软件称为IT系统，IT系统用来服务，好了我们可以把之前的观点结合起来下个定义：

云是一个可运营的IT系统，

但是这个定义缺少最关键的东西，就是资源迅速灵活地部署和回收。所以云当前最主流的定义为：

云是一个智能IT系统，它是：

• 可运营的
• 可以迅速灵活部署
• 可迅速回收资源的

也就是

云是一个可运营的，迅速灵活部署和回收资源的智能IT系统。

那么云应该具有如下性质：

• 云提供商拥有一定规模的硬件基础（计算、存储、网络）
• 作为服务进行交易，而不是实物交易，客户只是租用资源

也就是云其实是一种商业模式，如果认为只有底层使用了硬件集群和虚拟化技术的系统才是云这种观点是非常狭隘的。

谁催生了云

谁催生了云？当然是需求

传统IT的问题

互联网以及智能终端的普及，让信息得到了爆发性的增长，那么对IT基础架构（计算、存储、网络）来说，正在快速被饱和。

我们可以看看传统IT怎么运作的？比如运营商部门分析出网页游戏业务会有20%的增长，所以需要扩容，比如增加Web服务器、数据库服务器、存储系统的数量或容量，然后需要采购设备，遵循一系列的流程，这样周期非常的长，甚至慢于业务的变化周期。

但是另外一个部们的在线视频业务因为业绩不好，利用率不足60%。

当然最原始的想法是将在线视频业务的的40%余量分配给网游部门，不过会存在大量的技术风险。比如两种业务部署在同一个操作系统，会增加业务的粘度，不利于运维，然是如果把业务部署在不同的服务器上，更不利于运维。

加上现在数据中心中存在不同的协议、不同厂商的设备，如果靠手动来部署、管理和回收资源，效率低而且容易错，业务上线的速度也不快。

我们总结一下，传统的IT系统存在三个问题：

• 业务部署周期长
• 资源不能充分回收利用，存在孤岛
• 手动部署无法满足需求。

这就痛点。

云其实是商业模式

不过上面的说法只是云诞生的一部分理由，实际上最初的云，实际是一种商业模式，当商业模式与计算机技术结合之后，才产生了云这个代名词。这也是云没有外在的像技术一样严格的标准的原因。

系统架构变化

要解决之前提到的业务部署周期长，无法实现自动化，资源不能方便的回收和复用等，最容易想到的技术手段自然是虚拟化。

服务器虚拟化，即虚拟机系统，充分利用了资源，再加上Vmotion,DRS(Distrubted Resource Scheduler)等技术，极大的增加了部署灵活性和资源均衡性。

我们来看看部署了虚拟机以后对之前的问题带来的变化。

• 资源充分利用问题：旧业务余量会自动回收，新业务所需的应用可以直接以虚拟机的形式部署在物理机，因为操作系统各用各的，粘合影响得以避免。
• 上线业务周期长的问题：部署虚拟机消耗的时间比物理机少了很多，上线速度加快
• 手动部署问题：使用一种资源自动化分配和回收平台来解决自动化部署问题。

那么所谓虚拟化，其实就是在传统的数据中心上加上一个弹性层，这样整个数据中心就变成了软数据中心了。

如果还能做到部署回收自动化、可度量化、服务化、可运营的数据中心，则就是一个云数据中心了。

综上所述，云系统中重要的角色有：

• 虚拟化
• 集群化
• 自动化：实现资源自动部署、调度、分配、回收的管理者
• 对内可以与其他组件进行通信，管理资源
• 对外可以响应业务部署的需求，并且将这些需求转化为对内的资源调度
• 这个模块综合起来就是“自动化”。
• 可度量化：
• 也就是用户用了什么资源，为期多少时间，耗费多少成本，毛利率几何，报价几合可以精确度量、定价。

纵观云发展的过程中，说不清到底是先有云这种商业模式还是先有云这种技术架构的，两者其实是相互催生、相辅相成。

回顾存储系统的技术发展过程。

• 最开始的时候，存储系统只需要关心数据存储，只要提供一块空间，怎么管，怎么用，底层是不关心的，
• 后来，存储系统开始注重数据管理，开发了诸如快照、重删、容灾等功能。
• 再后来，又到了数据运营阶段，还关心数据怎么用的问题，此时需要更贴近用户的应用，注重业务展现。

公有云和私有云

现在我们已经有了一个云化的数据中心了，那么可以按照数据中心的是对企业内部开放服务还是给任何人开放服务来分为私有云和共有云：

• 私有云：数据中心对企业内部开发，提供云服务，比如存储空间申请、企业应用系统的快速部署等。
• 公有云：对外营业，通过互联网提供各种云服务。
• 私有云让企业IT部门角色转变
• 传统的IT部门是一个支撑部门，始终处于业务部门的牵引之下，所有的采购、经费申请必须以业务需求为前提。
• 那么怎么提升IT部门的地位，只要也得与业务部门处于平等的地位。云中的“服务”两字正好满足了这种需求，比如IT部门可以通过建立规范的资源申请流程，然后建立电子工单审批系统，只有通过审批以后才提供对应的服务。还可以统计某个部门在某段时间内使用了多少IT资源，消耗了多少成本。
• 这样IT部门成为一个独立的服务角色，其他部门向IT部门申请资源的时候，是以协商的态度而不是强势的牵制的态度，而且因为资源可度量了，IT部门可以做出合理的预测，申请后续经费等资源变得更有说服性。
• 公有云受制于互联网带宽发展
• 如今互联网的接入速度还是比较低的，大量用户的速度还是1Mbps，也就是只有100KB/s的吞吐量的接入速度。此时，若给他一个iSCSI协议访问的存储空间是不现实的，最多提供网盘这样的上传下载服务。
• 常用的SaaS服务（网页、聊天、视频、网盘等）基本上可以基于低速网络，但是IaaS就困难了，比如访问虚拟机的时候，如果不是用xshell这种方式，而是使用虚拟桌面登录，1Mbps非常勉强。而且，如果要安装软件，还得把安装包传上去。

综上所述，云目前最能被广泛推进的地方就是新建数据中心，企业兴建私有云，运营商兴建混合云

云系统架构及组成

下图为云具体的架构：

分为如下几个层次

• 物理架构层：比如供电、散热等
• 基础IT架构层：包括网络、存储、服务器等
• 需要注意的是这些服务器与存储设备不是孤岛，他们会组成集群，上面搭载虚拟化，并进行自动化的管理。
• 基础架构/集群管理层
• 有了集群还不够，需要在上面覆盖虚拟化层来增加系统的弹性。
• 对于服务器就是VMware这样的虚拟机平台。对于存储，就只能分布式文件系统或者分布式卷管理系统才能满足这种需求。
• 资源部署层：
• 现在我们已经可以得到一个网络、服务器、存储的集群，还需要一个用来管理和驱动集群的角色。
• 比如VMware的VSphere可以进行计算资源的包裹，分布式系统可以进行存储资源的包裹。
• 利用VSphere提供的Vmotion与DRS可以将虚拟机在集群节点中灵活移动，自动资源动态分配和回收。
• 中间件层
• 应用层与资源层需要一个中间层来适配，这就是中间件层
• 应用引擎层
• 这一层需要提供一个通用的业务开发平台，可以实现统一发布。
• 业务展现与运营层
• 现在数据中心的架构已经具有集群化、虚拟化、自动化的形态了，但是这只是对自己有用，对用户来说，他们不用关心底层用不用集群或者虚拟化，只关心是否能得到快速的服务和响应
• 所以我们还需要一个业务展现界面，这就是云服务。

那么出租数据中心其实可以在以下几个层次中进行：

• 基础设施即服务（IaaS）
• 所谓基础设施指的是云系统中的硬件设施如服务器、网络、存储。所以IaaS只是提供硬件平台，具体的计算任务由用户自行部署。
• 如何卖存储空间：
• 可以有多种方式，比如卖裸空间、文件存储空间等。
• 裸空间就是最终用户看到的是一块硬盘，所有协议当然首选ISCSI，以便跨越IP网络，这样用户可以通过ISCSI Initiator连接云提供商的ISCSI Target，然后就可以获得多个LUN。
• 对于云中存储系统，精简重删这些特性应该是必须的，可以降低不必要的空间占用，而动态分级可以进一步节省存储成本。
• 如何卖服务器、虚拟机
• 虚拟机平台需要考虑几种功能：
• 一是动态迁移，即虚拟机可以在不影响应用系统的情况下在物理机之间进行迁移。
• 二是资源动态分配调度，
• 三是管理方便。
• Amazon在IaaS提供两个产品：弹性计算云（Elastic Compute Cloud , EC2）和简单存储服务(Simple Storage Service ,S3)，分别对应了主机计算集群和存储集群
• 平台即服务
• 相对于IaaS，PaaS屏蔽而不出租基础架构，转而出租更高一层的软件平台。用户可以通过这个平台制作应用。因为这个平台是一种运行与硬件集群中的软件，用户实际上相当于租用了计算业务。
• 软件即服务
• SaaS是云服务中的最外层，直接出售业务级别的内容。比如Web网页等。

实例说云

下面使用3Tera Applogic的例子来说一下IaaS层

3Tera的IaaS平台名为Applogic，是一不可以实现IaaS功能的软件虚拟化平台。我们可以看一下它的底层架构：

主要分为4大层次：

• 硬件层：
• 本层包含服务器、存储、网络设施等。
• Applogic不要求底层存储必须是基于SAN的，可以是本地IDE。若干服务器通过千兆以太网连接起来，形成集群。
• 然后在这个有限且分配不灵活的资源池上，实现一种管理方便、使用方便、资源灵活分配的虚拟化层。
• 分布式核心虚拟化层(Applogic OS)：
• 计算虚拟化：Distributed Virtual Machine Manager（DVM）
• 本层的核心是虚拟机技术，通过Hypervisor引擎来虚拟化成多个主机，比如说VMware的ESX Server就是实现这个目的的。只不过Applogic使用的是Xen虚拟机平台。
• 存储虚拟化：Global Volume Store(GVS)子层：
• Applogic使用的是自研分布式文件系统，在这个文件系统之上虚拟出Volume，而且Volume可以Mirror、Clone、Snapshot等。
• 每个Volume在多个物理主机上有镜像以解决HA问题，并且可以提升读性能。
• 而这些Volume对于最终的虚拟机就是裸磁盘，在这个虚拟化层上，每个节点将自己的本地存储空间贡献出来，所有节点的存储被整合起来进行虚拟化。
• 网络资源虚拟化：Logical Connection Manager(LCM):将物理网络搞成虚拟网络
• 一次性基础设施虚拟层
• 所谓一次性基础设施，其实就是虚拟机可以按需创建。每个应用程序可以分配一个独立基础设施，包括防火墙、负载均衡、Web服务器、数据库服务器等。当要删除应用程序的时候，可以直接把虚拟机删除了。
• 这些角色可以虚拟成一个个对象，在图形界面使用鼠标拖拽的方式建立对象

• 上图创建了一个防火墙、负载均衡、2台Web防火墙、数据库服务器，整个网格中的Volume按照Application进行隔离，不同的Application只能看到自己的Volume。
• 防火墙、负载均衡、WebServer之间互联的IP用户不需要关心，系统自动分配，唯一需要配置的是整体Application的IP地址信息。
• 网络控制层和应用程序管理层
• 以Application为单位向用户交付。

Applogic带来的革命是把复杂的底层硬件变得简单，通过拖拽对象来状态自己的基础架构，最终以适合某中Application运行的整体服务器&存储&网络来交付。

云的缺点

在看云的缺点之前先看一下云的优点：

• 避免资源的浪费：
• 节能
• 角色转变

存在的问题：

• 稳定性和安全性：如何解决两个存储资源互通的问题，如何才能保证完全隔离。
• 平台迁移
• 怎么样才能在不影响业务的前提下迁移到云平台上。
• 不兼容的问题：不同云服务商提供的架构不同，接口也不同。

云之后的发展

云的本质

云本质是一种服务，而不是一种物质，正因为此，它必须基于物质才能显示功效，《易经》有云：“形而上者谓之道，形而下者谓之器”。所以下器者，谓之服务器 存储 部署管理软件；上道者，谓之“云”。所以云是一种道，是一种方式和方法，而不是某种设备，某个软件，当然云需要由硬件 软件来承载而已。

所以，云和速度性能没有直接关系。云本身不一定就是一个高速高冗余的东西，而是说底层硬件一般使用并行计算集群和存储集群，在这个基础上，云才能表现出更大的效能。

而且云也不是为了提速而生，它的主要目的是廉价高效的利用资源并降低硬件的应用成本和管理成本。

其实云早就存在了，只有近两年才被炒作起来，互联网服务器就是云服务，所以有人提出IT服务即云，Everything as a service。

其实在40年前，我们还是用集中分时计算，随后到了世纪相交的纪念，用户各自购买基础架构进行计算和存储，然后又逐渐回到了集中计算的时代，实际上这既不是进化，又不是退化，是“分久必合，合久必分。万物皆在轮回中不断发展，到一定程度就回到当初的形态，但是承载它的物质是连续不断的提升的。所轮回的只是其上的那层能量，谓之道。

Micro、Mini、Normal、Huge、Grid弹性数据中心

弹性核或者软数据中心：将若干刀片与高密度的磁盘柜以及微型交换机打包到一个或者几个机柜里面，再覆盖以弹性层，比如虚拟机管理系统以及分布式存储系统，将这样一个微型弹性软核心做为一个可提供IaaS服务的整体交付给用户。

或者再在这个软核上覆盖一层业务展现于管理层，直接交付到SaaS层。一柜或者数柜交付的弹性基础设施，可以称为Micro Cloud

二、数据容灾

数据备份系统只能保证实际上被安全复制了一份，如果生产系统故障，必须将备份数据尽快的恢复到生产系统中继续生产，就叫容灾。

容灾可以分为四个级别：

• 数据级容灾：只是将生产站点的数据同步到远端。
• 与应用结合的数据级容灾：保证对应应用数据一致性。
• 应用级容灾：需要保证灾难发生以后，需要保证原生成系统中的应用系统在灾备站点可用。
• 业务级容灾：除了保证数据、应用系统在灾备站点可用，还要保证整个企业的业务系统仍对外可用，是最终层次的容灾。

概述

如果要充分保证数据的安全，只是在本地做备份是不够的，所以需要在远程建另一个系统，并包含当前生产系统的全部数据，这个系统须

• 要保证主生产系统的数据实时的传输到远程备份系统上。
• 主故障后，必须将应用程序切换到远程备份系统上。

那么备份和容灾有什么区别呢？生产系统就好比手机，备份就是把手机上的数据备份到电脑上，但是如果这个手机坏了呢？要恢复数据需要大量的时间。

那么容灾就是我们有两部手机，而且他们的数据是使用云实时同步的，所以可以无缝切换。

如果我们预算充足，可以使用一直两台手机，那还需要备份吗？当然需要，比如某个时刻，我们把手机里面的某个联系人给误删了，因为容灾的手机是实时同步的，很难说能通过另一部手机找回来。但是如果之前有备份过数据，完全可以通过之前的备份进行恢复。

下面继续谈容灾。对于一个企业IT生产系统，主要有4个组件：

• 生产资料：原始数据
• 生产工具：服务器等基础架构
• 生产者：业务应用程序
• 产品：对外提供的服务信息

下面将对这四大组件的容灾进行讲解

生产资料容灾

生产资源容灾指的就是对原始数据进行容灾。这最重要的，因为没有生产资料一切等于从头再来。

要设计这样一套生产资料容灾，需要注意的是

• 要把变化的实时同步到备用系统，方法是
• 将某时刻的数据传送到备用系统
• 将此时候后变化数据同步到备用系统
• 这样就做了一次同步了，之后只需要在数据变化以后才把变化的数据传送到备用系统。
• 数据必须至少保留额外一份。在容灾的同时还需要数据备份（避免误删等逻辑错误）

如下为相应的拓扑：

主备站点都有相同的生产工具，使用网络相连。可以通过两种方式来进行同步：

• 通过前端网络进行同步
• 通过后端SAN网络进行同步。

通过前端网络同步

• 通过路由器连接到专线或者Internet
• 变化的数据通过路由器传送到备站点的路由器上。
• 通过交换机传到备服务器上，写入磁盘阵列

那么到底选择专线还是Internet呢？专线可以保证数据同步的实时性，但是不适合大数量的传输。如果实时性要求不高，而且数据量大的时候，可以将主备站点接入100Mbps的Internet。

可以看出这种方式经过了前端网络，所以必须在每台需要备份的服务器上安装软件进行同步，这种软件可以监视目录中的数据变化，然后与远端的软件进行通信，写入相同的文件目录中。

这种方式的同步一般都是文件级的同步，对底层卷的数据块变化不做同步。

案例：DB2数据的HADR组件容灾

DB2数据库利用主备上的数据库软件模块（HADR）来实现两端的数据同步。而且同步的是不卷上的原始数据，而是对数据操作的描述，也就是日志。这样的好处是，不需要传输数据，备份机收到日志以后，在备机的磁盘上重做操作即可。

HADR:High Availability Disaster Recovery，是数据库级别的高可用性数据复制机制。需要两台数据库服务器：primary , standby

• 当主数据库发生事务性操作，将日志通过TCP/IP传送到备数据库，然后备机对日志文件进行重放Replay，从而保持数据的一致性。
• 当主数据库故障，备机可以接管主数据库，而客户端应用程序的数据库连接可以通过自动客户端重新路由（Automatic Client Reroute）转移到新的主服务器。
• 当原来的主数据库服务器修复了，作为新的备用数据库加入HADR。

需要注意的是处于备用角色的数据库不能被访问。

通过后端网络实现同步

通过后端网络进行同步，数据不会流经前端网络，而全部通过后端网络传输到备份的存储上。所以需要将主站点和备站点的后端网络设施连接起来。要么直接拉光纤，要么用专线。

如果用专线的话，需要增加额外的协议转换设备，现在电信部门的光纤专线一般为SDH传输方式，接入到用户端的时候，一般将信号调制成E1、OC3等编码方式。

上图中，FC协议，经过FCIP网关，变成基于以太网的IP协议，（FC over IP over ETH）。经过E1/以太网转换器，承载到了E1协议上，然后多路E1信号汇聚到光端机，通过一条或者多条光纤，传输给电信部门的SDH交换设施进行传输。

这样我们就将主站点和备站点的后端网络打通了，此时主服务器就可以访问到备份的磁盘阵列，也就是说主站点的服务器可以同时操作本地磁盘和备站点的磁盘阵列了。

我们来看一下这种方式的路径：

本地磁盘 SAN交换——本地服务器内存——SAN网络交换——电信部门网络——远端SAN网络交换——远端磁盘阵列

数据到了远端SAN不需要再经过服务器，因为有了对方存储设备的直接访问权。但是整个过程中，仍然至少需要一台服务器，服务器上需要安装一个软件，可以将数据从本地卷A提取出来，然后直接通过SAN网络写到位于备份站点的卷B上。

但是试想一下，如果数据直接在内存中生成的，那么同时在A和B上各写一份，速度岂不是更快，这种方式又叫“卷镜像”，因为可以时时刻刻保持两个卷完全相同，它能保证数据同步的实时性，但是不适合大规模远距离的数据同步。

同时还需要注意的是，卷镜像的的同步软件工作在卷这一层，可以感知数据块的变化，而不是文件的变化。缺点在于对网络速度要求更高，所以成本也更高。

通过数据存储设备实现同步

之前讲的通过前端网络和通过后端网络的方式，都使用了一个泵来提供动力。而如果将数据同步软件安装在存储设备上，岂不是更省事。而且这样彻底解放了服务器，所有工作都由磁盘阵列完成。

这种方式的同步，不会识别卷上的文件系统，所以同步的是块。而且要求主和备的存储设备型号一致。因为不同厂家的产品无法实现直接同步。

这种方法的缺点是不能保证数据对应用程序的可用性。

因为存储设备与应用程序之间还有操作系统这一层，操作系统也有自己的缓存机制，所有有可能造成数据的不一致性。

总结：

• 使用前端网络进行同步，路径最长，但是成本也最低。
• 使用后端网络进行同步，实时性强，但是对后端链路要求也高。不适合于数据量多的时候。
• 使用存储设备直接进行同步，路径最短，不占用服务器。但是仍然不适合于远距离低速链路环境。而且还不能数据对应用程序的可用性。

容灾中数据的同步复制和异步复制

同步复制

下图是基于存储设备的自主同步环境。

• 主向磁盘发出IO请求，向某LBA写入数据，待写数据入缓存，此时控制器不会给主的HBA驱动程序发送成功
• 主磁盘阵列将变化的数据从缓存中写入LUN A，此时主的数据同步引擎感知，将变化的数据块从缓存中通过SAN交换机发送到备的缓存中。
• 备磁盘阵列运行的同步引擎接收到数据后，在FC协议隐式的发一个ACK或者通过上层显试的发给主站点
• 主收到应答，向服务器发一个FC协议的隐式ACK。服务器上的FC HBA驱动程序探测成功。
• 若备站点迟迟未收到数据，则不会返回成功，应用程序会等待。如果此时应用程序使用的是同步IO，则相关进程会挂起，称为IO等待。
• 所以同步复制的特点是主站点必须等待备份站点的成功信号，保持严格的同步，一荣俱荣，一损俱损。

异步复制

相对于同步复制，两边的步调不需要一致，要保证重要的事情先做完，所以会存在一定的数据不一致。

• 主向磁盘发出IO请求，待写数据进入控制器缓存，如果此时
• 主控制器设置为Write Back模式：则立刻返回应答。
• 主控制器设置为Write Through模式，则先写入LUN A以后，再返回ACK。
• 主站点将数据通过SAN网络发送到备站点的缓存。
• 备站点磁盘成功接收，则返回成功。

生产者容灾——应用程序容灾

之前讲的都是生产资料的容灾，也就是整个系统最重要的数据的容灾。而对于生产者，无疑就是服务器上的应用程序，如果主发生故障，需要在备站点重新运行这些应用程序。最直观的想法是，在备站点预备应用程序的安装文件，一定主出现故障，在备上配置这些应用程序，但是实际上应用程序安装和配置需要大量的时间。所以可以将备份站点预装应用程序，但是不工作，这样就可保证同一时刻整个IT系统只有一个站点的生产者处理一份数据

既要求处理同一份数据，又要求发生事故的时候，备份站点的生产者立即启动，要做到这点，需要让备份站点的应用程序感知到主站点的应用程序状态，一旦发现故障，立即启动开始生产。

在之前的章节中，我们说到了高可用群集，在容灾系统领域，群集的范围扩大到了异地，主备可能相隔很远，交换运行状态的数据量很小，最好使用专线，这样可以很好的保证QoS。

传统的HA软件是使用共享存储的方式来作用的，即在HA系统中，共享一份物理存储，不管谁来操作这份数据，最终只有一份，而且是一致，有上下文逻辑关系的。

所以HA软件是基于资源切换的，把组件看作是资源，比如应用、IP地址、存储卷等。

当故障时，

• 备份机HA软件会检测到对方的故障，
• 然后强行将资源迁移到本地，比如在备份机上修改网卡的IP地址，并发出ARP广播来刷新所有广播域的客户端以及网关的ARP记录
• 挂载共享存储设备上的卷，
• 最后启动备份应用系统。

这样应用系统可以访问共享卷，客户端也可以使用原来的IP地址来访问服务器，这样生产就可以继续下去。

但是在异地容灾系统中，主备站点各有一份数据，所以必须保证数据的同步。这也是为什么两个站点同时只有一个在工作，这样的话才能以一边数据为准，另一边与之同步。

本地容灾

本地HA系统中，多个节点如果共同拥有同一个卷，但是同一时刻只有一个节点能挂载它，这种模式叫共享存储模式

与之对应的是Share-Nothing模式，每个节点都有自己独占的存储卷，怎么进行数据共享呢？可以通过同步复制技术同步到所有节点上。若某节点发生故障，这个节点对应的备份节点启动应用程序。因为之前的数据已经同步过了，所以数据一定是一致的。

在Share-Nothing模式下，不存在任何的接管问题，所以客户端需要感知服务端群集这种切换动作，通过客户端进行配置的切换即可。

可以对共享存储和Share-Nothing两种存储模式进行对比。

共享存储Share-Nothing数据本身是否容灾×√软硬件成本高低前端网络资源消耗低高管理难度高低维护数据是否需要停机√×实现的复杂度高低是否需要第三方软件√×故障因素数量3个2个

• 数据本身是否容灾
• 共享存储：数据损坏，必须使用镜像进行还原。而且要停机。
• Share-Nothing：每个节点都有自己的数据拷贝，若损坏，可切换到另外的节点，不影响应用，不停机。修复后的节点可以重新加入容灾系统。
• 软硬成本
• 共享：需要外接磁盘阵列，为了保证数据访问速度，必须自身实现RAID，主机也需要安装适配器。成本高。需要HA软件
• Share-Nothing:各个节点各自保存数据，不需要外接存储系统，不需要额外的HA软件
• 前端网络耗费
• 共享存储：前端只需要交互控制信息，资源耗费较小。
• Share-Nothing:数据同步靠前端，对资源消耗很大。
• 管理难度：
• 共享：需要管理节点间的交互配置，还需要管理外部存储，增加了管理难度
• Share-Nothing:只需要管理节点配置。
• 是否停机
• 共享：需要将数据从单机转移到共享存储供其他节点使用，需要停机来保证一致性。
• Share-Nothing：数据同步是动态的，不需要停机。
• 实现复杂度
• 共享存储：有三种基本元素：节点、节点间的交互、共享数据。如果使用共享存储模式做容灾，需要将数据移动到共享存储上，增加额外的工作量和不可控因素
• Share-Nothing：只有两种元素 节点&节点交互
• 第三方
• 共享存储：备份节点需要通过HA软件来监控主节点的状态，发生故障的时候自动接管，如MSCS
• share-Nothing：不需要第三方软件参与
• 故障因素
• 共享存储：OS、应用程序、HA软件
• Share-nothing：OS、应用程序

异地容灾

如果主站点和备站点不在同一个机房中，这样备份应用程序需要跨越很远的距离来与主程序交互状态。只是说这种交互包很小，不需要担心延时的问题。

IP切换

在异地容灾系统，主服务器和备服务器不大可能在同一个广播域，所以需要通过网关来转发IP包，正因为此不能用资源切换的方式来切换IP地址。

如果想故障后，客户端继续使用原来的IP地址连接备份服务器，那么可以在路由上做文章。动态修改路由器上的路由表，将IP包路由到备份站点而不是主站点。如果利用域名来访问服务器，那么可以直接在DNS设备上修改IP指向记录来实现。

卷切换

异地容灾系统在主站点和备站点各有卷，两个卷通过前端或者后端网络进行同步。

如果备的HA软件检测到主站点通信失败，通过某种方式，断开同步关系（若不断开，卷会被锁定而不可访问）。然后就是重新挂载备站点的卷

此时同步引擎可以是运行在存储设备上，也可以由HA来执行。

• 如果同步引擎是运行在存储设备上的，必须由管理员手动利用存储设备的配置工具来断开同步关系。断开了以后，本地的卷才可以被访问，然后HA软件可以在备份机上调用操作系统相关功能来挂载这个卷。
• 如果同步引擎本来就是HA来执行的，那么HA软件可以自动断开同步关系，在备份机上挂载对应的卷。

异地容灾的应用切换

应用，也就是生产者的切换，是所有HA容灾系统在故障发生后所执行的最后一步。与共享存储式的HA容灾一样，异地容灾的应用切换，是有备机的HA软件来执行脚本，或者调用相应的接口来启动备份机的应用的。

三、数据保护和备份技术

从底层来分，数据保护可以分为文件级保护和块级保护。

文件级备份

文件级备份：将磁盘上所有文件通过调用文件系统接口备份到另一个介质上。也就是把数据以文件形式读出，然后存储在另一个介质上面。

此时备份软件只能感知到文件这一层。

我们知道一般来说，文件在原来的介质上，可以是不连续存放的，通过文件系统来管理和访问。当备份到新的介质上以后，文件完全可以连续存放。正因为如此，没有必要备份元数据，因为利用新介质进行恢复的时候，反正会重构文件系统。

块级备份

块级备份就是不管块上是否有数据，不考虑文件系统的逻辑，备份块设备上的每个块。

这样好处是不通过调用文件系统接口，速度更快，缺点的是备份的时候会把所有的块复制一遍，但是实际上很多扇区的数据是不对应真实文件的，也就是会备份很多僵尸扇区。而且备份之后，原来不连续的文件一样是不连续的文件，有很多的碎片。

高级数据保护

远程文件复制

远程文件复制：通过网络传输到异地容灾点。典型的代表是rsync异步远程文件同步软件。可以监视文件系统的动作，将文件的变化，同步到异地站点。增量复制。

远程卷镜像

这是基于块的远程备份。与远程文件复制不同的地方在于，是把块数据备份到异地站点。又可以分为同步和异步复制。

• 同步复制：必须等数据复制到异地站点以后，才通报上层IO成功消息
• 异步复制：写入成功即可回复成功，然后通过网络传输到异地。不能保证一致性，但是上层响应快。

基于块的备份措施，一般都是在底层设备上进行，不耗费主机资源。

快照

远程镜像确实是对生产数据一种非常好的保护，但是需要镜像卷一直在线，主卷有写IO，那么镜像卷也需要有写IO。

如果想对镜像卷进行备份，需要将停止主卷的读写，然后将两个卷的镜像关系分离。所以当恢复主卷的IO的时候，镜像卷不会再被读写。然后才可以备份镜像卷的数据。

这样会存在一个问题，主卷上还继续有IO，将会导致数据与备份的镜像不一致。所以主卷上所有的写IO动作，会以位图bitmap方式记录下来，bitmap上的每个位表示卷上的一个块，0表示未写入，1表示已写入，所以当拆分镜像以后，被写入了数据，程序将bitmap文件对应位从0变为1。备份完成以后，再做数据同步即可。

可以看出上述过程比较的繁琐，而且需要占用一块和主卷一样大小的镜像卷。

快照技术就是为了解决这种问题，其基本思想是抓取某一时间点磁盘卷上的所有数据。

快照分为：基于文件系统的快照和基于物理卷的快照

下面介绍一下快照的底层原理。

基于文件系统的快照

文件系统管理的精髓：链表、B树、位图，也就是元数据

文件系统

• 将扇区组合成更大的逻辑块来降低管理规模。NTFS最大块可以到4KB，也就是8个扇区一组一个簇（Block），这样可以减少管理成本。
• 文件系统会创建所管理存储空间上所有簇的位图文件。每个位代表卷上的簇（或者物理扇区）是否被使用，如果被使用，则置1。
• 文件系统保存一份文件和其对应簇号的映射链。因为映射链本身和簇位图也是文件，也有自己的映射链，所以针对重要的元数据，有一个固定的入口：root inode

写入新数据

• 查找簇位图，找位值为0的簇号，
• 计算所需空间， 分配簇号给文件
• 将数据写入簇，再去文件——簇号映射图更新
• 将对应的簇映射关系记录下来，到簇位图将对应位置改为1.

删除数据

• 直接在簇号映射链中抹掉，
• 簇位图对应簇改为0

可以看出删除数据实际上不会抹掉实际的数据。

** 所以，最重要的不是数据，而是文件——簇号映射链和位图等元数据。**

也就是说我们要做备份，只需要把某时刻的文件系统中的映射图表保存下来。但是必须保证卷上的数据不被IO写入了，同时又要不应用还不能中断。既然原来的空间不能再写了，我们可以写到其他的空闲区域。

• 思路一：Copy on First Write (CoFW)，
• 在覆盖数据块之前，需要将被覆盖的数据块内容复制出来，放到空闲的空间。
• 系统中将有两套元数据链，原来的元数据指向当前，快照的元数据链指向历史。原来的存储空间永远是最新的数据，历史数据会逐渐搬出到空闲空间里面。

• 思路二：Redirect on First Write,(RoFW)。
• 先复制元数据，然后将针对源文件的更改都重定向到空余空间，同时更新元数据。
• 与CoFW不同的是，原来的数据块不会被覆盖。同样的，系统也有两套元数据，一套是快照保存下来的，永远不更新，一套是源文件系统的，不断的更新。
• 其实只有首次覆盖的时候，才重定向，因为重定向以后的数据块，哪怕被覆盖了，也不影响之前快照保存的数据了。

下图为生成两个快照之后系统处理流程。

到这一步，看上去挺完美，实际上存在一个问题：如果元数据特别大怎么办？对于海量庞大的文件系统，元数据量可能到GB级别。如果复制的话，时间上仍然太多。

我们可以回头想想，实际上元数据可以看做指针，指向具体存储的位置。我们复制到元数据，相当于复制了一堆指针。现在元数据太多了，我们能不能把这个元数据链的指针给复制了？当然可以，元数据有个根入口块，或者称为Super Block，这个块是固定不变的，里面存放有指向下一级元数据链块的指针。

那么操作系统每次载入元数据的时候，都需要从这个地址读入Super Block，从而一层一层的遍历。

下图为只复制Super Block以后的RoFW模式：

基于物理卷的快照

基于物理卷的快照比文件系统快照要简单得多。因为LUN一般在底层磁盘上是恒定的，不像文件系统一样可以随机细粒度的分布。所以可以认为LUN的元数据就是在底层磁盘的起始和结束地址

这样在快照的时候，需要复制的元数据就更少了，但是完成了以后，需要按照一定粒度来做CoFW或者RoFW，还需要记录更多数据映射指针，就比较难受了。

对于实现了块级虚拟化的系统如NetApp,XIV,3PAR等，它们的LUN在底层位置是不固定的，LUN就相当于一个文件，存在元数据链来进行映射管理的维护，所以这些系统实现快照的原理与文件系统快照类似。

基于物理卷的快照，相当于给物理卷增加了“卷扇区映射管理系统”。在底层卷实现快照，可以减轻文件系统的负担。

卷扇区方都是用LBA来编号的，实现快照的时候，程序首先保留一张初始LBA表，每当有新的写入请求的时候，重定向到另一个地方，并在初始的LBA表中做好记录。比如

原始LBA：卷A的10000号，映射到LBA：卷B的100号。

值得说明的是，文件系统无法感知重定向，文件系统在它的映射图里面还是记录了原始的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资源消耗：

• CoFW方式下，如果要更新一个从未更新的块，需要复制出来，写到新卷，然后覆盖原来的块，需要：一次读，2写。
• RoFW方式下，只需要一次写即可，也就是直接重定向到新卷上，然后更新映射图中的指针（在内存中进行）。

所以RoFW相对CoFW方式在IO资源消耗与IO延迟上有优势。

由于只有首次覆盖才会Copy或者Redirect，那么如何区分是否是首次覆盖呢？可以使用记录表（文件级快照）或者位图（卷快照）来记录每个块是否被覆盖过。

对于读IO，

• CoFW：因为总是更新的源卷，所以源卷总是代表最新的状态，所以任何读IO都会发到源来执行
• RoFW：需要首先查询位图来确定目标地址是否被处理过，如果是，则转向重定向后的地址。
• RoFW会影响读性能，因为重定向出去以后，数据块排布都是乱的，如果把快照删除后，不好清理战场，严重影响后续的读写性能。

综合来说，RoFW比较吃计算资源，而CoFW比较耗费IO资源。

我们知道其实一般来说读比写多，当覆盖第二次以后

• CoFW不会发生IO惩罚，读IO一直没有惩罚
• 对于RoFW，就算完全被Redirect过了，对于读或者写IO，均需要遍历位图，永远无法摆脱对计算资源的消耗。

尤其在LUN卷级快照下，原本卷在底层磁盘分布式是定死的，寻址非常迅速。但是RoFW引入了，LUN的块随机定向到其他的空间的，所以需要记录新的指针链，而且被写出的块不是连续排列的。对性能影响非常明显的。

绝大多数的厂商使用的还是CoFW，但是一些本来就使用LUN随机分块分布模式的存储系统比如XIV,NetApp等，都使用RoFW，因为原本其LUN的元数据链就很复杂，而且原来就是随机分布的，RoFW的后遗症对它们反而是正常的。

快照的意义

快照所保存下来的卷数据，相当于一次意外掉电之后卷上的数据。怎么理解?

上层应用和文件系统都有缓存，文件系统缓存的是文件系统的元数据和文件的实体数据。每隔一段时间（Linux一般是30s）批量Flush到磁盘上。而且不是只做一次IO，有可能会对磁盘做多次IO。如果快照生成的时间恰恰在这连续的IO之间，那么此时卷上的数据实际上有可能不一致。

文件系统的机制是先写入数据到磁盘，元数据保存在缓存里面，最后再写元数据。因为如果先写元数据，突然断电了，那么元数据对应的僵尸扇区的数据会被认为是文件的，显然后果不堪设想。

总之，快照极可能生成不一致的数据。

那么为什么还要用快照呢？

• 因为快照可以任意生成，而且占用的空间又不大，更重要的是可以在线恢复，不用停机只需要在内存中做IO重定向，那么上层访问就变成以前时间点的数据了。

但是快照会存在不一致的问题，如何解决？

既然快照无异于一次磁盘掉电，那么利用快照恢复数据之后，文件系统可以进行一致性检查，数据库也会利用日志来使数据文件处于一致。

另外，现在主流的快照解决方案是在主机上安装一个代理，执行快照前，先通知文件系统将缓存中的数据全部Flush到磁盘，然后立即生成快照。

• 快照还可以预防数据逻辑损坏，也就是比如T1时刻，做了快照，T2时刻，因为管理员操作不当，误删了一个文件，T3的时候，进行了全备份操作。此时，这个文件看似永久丢失了，其实，此时还可以通过快照恢复这个文件。
• 快照还可以降低一致性备份的窗口。如果没有快照，要对某个卷进行一致性备份，需要暂停写IO，所以备份窗口比较长，需要等待备份停止以后才能继续写IO。使用快照的话，只需要复制元数据，然后在后台进行备份，降低了影响。
• 备份完毕以后，如何能检测数据是否是真一致的？若没有快照，需要将备份数据恢复到独立的物理空间里面，挂载到另一台机器上。有了快照，可以将快照直接挂载到另一台主机，避免了数据物理恢复导入的过程。

卷Clone

快照类似于某时刻的影子，而克隆则是某时刻的实体。每时刻生成了一份可写的快照，就叫对卷某时刻的一份Clone。然后这份Clone内容每被修改的部分是与源卷共享的，所以源卷没了，则Clone就没了，所以叫虚拟Clone

如果把数据复制出来，生成一个独立的卷，则就叫Split Clone，也就是可以得到实Clone。

卷Clone最大的好处在于可以瞬间生成针对某个卷可写的镜像，而不管卷的数据量有多大。

数据备份系统的基本要件

• 备份对象：需要进行备份的备份源。
• 备份目的：磁盘、磁带等介质
• 备份通路：网络
• 备份执行引擎：备份软件
• 备份策略

下面重点介绍一下备份目的、备份通路、备份引擎

备份目的

备份到本地磁盘

备份目的地是在本地的磁盘，则只需要将数据备份到本地磁盘的另外分区中或者目录中。

这样不需要网络，缺点是对备份对象自己的性能影响大。还会对其他的IO密集型程序造成影响。

这种方式一般用于不关键的应用和非IO密集型应用。比如E-mail，对转发实时性要求不高。

备份到SAN上的磁盘

备份到SAN上的磁盘，就是将需要备份的数据，从本次磁盘读入内存，再写入HBA卡缓冲区，然后再通过线缆传送到磁盘阵列上。

• 优点：只耗费SAN公用网络带宽，对主体影响小。
• 缺点：对公共网络资源和出口带宽有影响。

备份到NAS目录

备份到NAS目录就是将数据备份到远程共享目录中。比如window中常用的文件夹共享。因为数据一般是通过以太网进行传递的，占用了前端的网络带宽，但是相对廉价，不需要部署SAN

备份到磁带库

现在出现一种虚拟磁带库，即用磁盘来模拟磁带，对主机来说看到的是一台磁带库，实际上是一台磁盘阵列，主机照样使用磁带库一样来使用虚拟磁带库。要做到这点，就必须在磁盘阵列的控制器上做虚拟化操作，也就是实现协议转换器的作用。

可以带来了的好处是：

• 速度提升
• 避免机械手这种复杂的机械装置
• 管理方便。

信息生命周期管理

将使用不频繁的数据移动到低速、低成本的设备上。比如只给视频应用分配20GB的空间，但是报告有500GB的空间，剩下的空间是在在磁带库上。

分级存储

1. 一线磁盘阵列
2. 二线虚拟磁带库：近期不会被频繁调度。利用大容量SATA盘，性能适中的控制器。
3. 带库或者光盘库。几年甚至几十年都不访问到。

备份通路

本地备份

数据流向：本地磁盘——总线——磁盘控制器——总线——内存——总线——磁盘控制器——总线——本地磁盘

也即数据从本地磁盘出发，经过本地的总线 和内存，经过CPU少量控制逻辑代码之后，流回本地磁盘。

通过前端网络备份

经过前端网络备份的数据流向是：

本地磁盘——总线——磁盘控制器——总线——内存——总线——以太网卡——网线——以太网——网线——目标计算机的网卡——总线——内存——总线——目标计算机的磁盘。

数据从本地磁盘出发，流经本地总线和内存，然后流到本地网卡，通过网络传送到目标计算机磁盘。

• 前端网络：服务器接受客户端连接的网络，也就是服务网络，是服务器和客户端连接的必经之路。
• 后端网络：对客户封闭，客户的连接不用经过这个网络，用与服务器和存储、应用服务器、数据库服务器的连接。可以是SAN，以太网

通过后端网络备份

通过后端网络备份的数据流向是：

本地磁盘——总线——控制器——总线——内存——总线——后端HBA卡——线缆——后端交换设备——线缆——备份目的的后端网卡——总线——内存——磁盘

LAN Free备份

备份的时候不经过LAN，也就是不流经前端网络，也叫Frontend Free。这样的好处是不耗费前端网络的带宽，对客户终端接受服务器的数据不影响。。

因为前端网络一般是是慢速网络 ，资源非常珍贵。无论是本地、还是网络，都需要待备份的服务器付出代价，即需要读取备份源数据到自身的内存，然后从内存写入备份的目的地。对主机CPU、内存都有浪费。

能否不消耗服务器的性能呢？可以，使用Server Free备份。

Server Free备份

Server Free备份：备份的时候，数据不用流经服务器的总线和内存，消耗极少，甚至不消耗主机资源。

备份源和备份目标都不会在服务器上，因为如果在服务器上，数据从磁盘读出，要流将总线，然后到内存，这就不是Server Free

那怎么做呢？

• 用SCSI的扩展复制命令，将这些命令发送给支持Server Free的存储设备，然后这些设备会提取自身的数据写入备份目的设备，而不是发送给主机。
• 使用另一台专门做数据移动的新服务器，来代替原来服务器移动备份数据。释放运算压力很大的生产服务器。

备份策略

备份引擎：决定整个数据备份系统应该怎么运作，备份那些内容，什么时候开始备份，备份时间有没有限制等的策略。

备份服务器

备份引擎以什么形式体现呢？当然是运行在主机上的程序，所以需要一台计算机来做引擎的执行者。

那么备份服务器的备份策略和规则，怎么传给整个数据备份系统中的服务器？通过以太网，因为以太网扩展性好，适合节点间通信。相对于以太网，SAN更适合传送大量的数据。所以常用前端网络来连接待备份的服务器和备份服务器，因为备份策略的数据包不多。

备份服务器如何与每个待备份的服务器建立通话？怎么通话？规则怎么定？需要待备份服务器上运行一个代理程序，专门解释备份服务器发来的命令，根据命令作出动作。

这个运行在待备份服务器上的程序，就叫备份代理，监听端口，接收备份服务器发来的命令。

介质服务器

若数据备份系统中有一台SCSI磁带机，且多台主机想备份到这台磁带机上。而SCSI磁带机只能同时接到一台主机上。

那么怎么办呢？可以引入一台专门的计算机，只能由这台计算机来操作磁带机。

需要备份的计算机通过以太网将数据发给这台掌管磁带机的计算机，然后写给磁带机。

这样磁带机成为了公用设备，而在整个系统中，只有一台计算机能掌管备份目标，它就类似于一个代理，代理其他服务器执行备份。我们把它称为介质服务器

还有一个问题，如果有多台服务器向介质服务器发出请求，怎么办?当然需要一个协调员，也就是备份服务器，它可以指挥安装在待备份服务器的代理，让每台服务器按照顺序有条理的使用介质服务器提供的备份介质进行备份。

三种备份方式

完全备份

不管文件多大，只要要备份，都需要将文件都备份下来。

差量备份

差量备份：只备份从上次完全备份以来发生变化的数据。

差量备份要求必须做一次完全备份，作为差量的基准点

增量备份

只备份从上次备份以来这份文件中变化过的数据。** 上次备份**，不管是全备、差备，还是增量备份。

对于数据库的备份，备份软件想知道每个数据文件的变化是不可能的，因为数据库文件内部格式非常复杂，只有自己才能分析和检测出来。所以数据库管理软件有自己的备份工具。第三方备份软件只能调用数据库软件自身提供的命令。

四、DAS , SAN和NAS

NAS

LUN只是一个卷设备，对主机而言就是一块硬盘，我们的操作系统集成了文件系统的功能，可以用来管理卷。而 NAS就是把文件系统从主机迁移到磁盘阵列上，自己来管理。使用者只需要通过网络告诉这个文件系统需要存取什么文件而不需要向NAS传递LBA地址。

那么NAS与SAN的区别是什么？

SAN是网络上的磁盘，NAS是网络上的文件系统。

• SAN：存储区域网络，是网络上的磁盘，其本质只是一个网络，包含了主机、适配器等一切后端存储相关的内容。可以说SAN包含NAS。
• 一般把FC网络上的磁盘叫做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呢？因为

• 最重要的原因是NAS成本更低，不需要昂贵的FC HBA卡和FC交换机。
• 基于以太网、TCP/IP，扩展性强
• 可以提供多种协议访问。网络文件系统通过HTTP、FTP等协议进行访问，而SAN只有SCSI协议。
• 采用专门的设备处理文件系统逻辑， 可以解放主机CPU和内存，适合在CPU密集的应用环境。
• NAS可以在一台盘阵上实现多台客户端同时访问。SAN的LUN一般只能分配给某个主机，只有通过集群系统对数据一致性进行了保证以后，才能实现LUN共享

所以单纯的讨论SAN好还是NAS好是没有意义的，我们更需要的是根据场景、成本等要素来决定到底使用NAS还是SAN。

我们可以把目前的应用分为两种：IO密集与CPU密集

• CPU密集：程序内部逻辑复杂，但是对磁盘IO访问量不高。比如高性能运算
• IO密集：内部逻辑不复杂，但是需要随时存取硬盘的，比如Web应用
• 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：最原始的存储：直接存储。存储设备只用与独立的主机。比如PC中的磁盘或者只有一个外部SCSI接口的JBOD

DAS（仅供自己使用）到SAN（出租仓库给其他的租户），到NAS(集中式理货服务外包)

SAN是一种网络，而不是某种设备。只要是专门向服务器传输数据的网络就可以称为SAN。

NAS设备通过以太网向主机提供文件级别的数据访问，以太网络就是SAN。

习惯性的将FC SAN架构称为SAN

NetApp的NAS

NetApp的NAS极大的借鉴了数据库管理系统的设计，本小节主要讲解一下NetApp的NAS的基本思想。

利用了数据库管理系统的设计

我们知道数据库管理系统是这样记录日志的，在某个时刻，数据库管理系统接收到应用程序的SQL更新语句，首先将数据修改前的状态以日志的形式保留在内存的日志缓存区，然后覆写原来的数据。

因为日志缓存区是内存的一部分，所以如果掉电则数据丢失，所以每隔一段时间或者说程序进行提交事务时，管理系统会把日志推到磁盘中。同理，也会把缓存中更新过的数据块写入磁盘。

只有当日志确实写入到硬盘上的日志文件中的时候，才会对上层应用返回执行成功。

具体过程可以参见数据库（五），事务。

NetApp借鉴了这种设计思想，它会将文件系统中的写入请求作为操作日志写入到NVRAM中保存。

NVRAM不用电池也可以在不供电的情况下保存数据，而NetApp使用的是带电池保护的RAM，下文姑且称其为NVRAM.

为什么要使用NVRAM而不像数据库一样使用文件来保存日志的呢？

对于数据库系统来说，先将日志写入到内存中日志缓冲区，再在触发条件下将日志写入磁盘上的文件。一旦意外掉电，内存中的日志没有来得及保存到硬盘就丢失，数据库再次启动的时候，会提取硬盘上的日志，对于没有提交的操作进行回滚。这样就保证了数据的一致性。

不过如果应用程序频繁提交，日志缓冲区的日志会频繁的写入到磁盘上，这时日志缓存就起不了什么作用了。

对数据库来说，上层的每个业务一般都算是一个交易，在尚未完成的时候，程序不会发送提交指令给数据库系统的，所以频繁提交的频率不高。

而文件系统则不然，上层应用向文件系统写入数据而言，每次请求都是完整的交易。也就是说提交会非常频繁。如果将操作日志写入磁盘，开销大，所以利用了带电池保护的RAM内存（NVRAM）。只要成功写入了RAM，就可以立即通知上层写入成功。

一定要搞清楚日志和数据缓存的区别。

• 日志是记录操作动作和数据内容，而非实际的数据块。保存在NVRAM中
• 实际的数据块保存在RAM中而非NVRAM中。

WAFL的做法是用RAM来保存日志，可以一次接收到上千条写请求，而且可以直接返回成功。等到RAM半满，由WAFL一次性批量连续写入硬盘，保证高效率。

WAFL从不覆写数据

当日志占了NVRAM空间的一半或者每10s，WAFL会将内存中已改写的数据以及元数据批量写入硬盘。同时清空日志，腾出空间。这个动作叫CheckPoint

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 ： 以ISCSI为代表的TCP/IP作为传输方式的网络存储系统，也就是基于IP的存储区域网络

当然IP SAN不一定用以太网作为链路层，可以用任何支持IP 的链路层，如 ATM 、PPP 、 HDLC 甚至是FC

同样用TCP/IP来进行传输，NAS与IP SAN有什么区别呢？

NAS传输的是文件系统语言。ISCSI传输是SCSI指令语言。所以IP SAN本质是SAN提供的是块存储

IP SAN相对于FC SAN最大的优势在于：

• FC SAN 成本是IP SAN的十倍。
• FC是专用网络，很难扩展
• 部署FC存储网络更复杂
• 兼容性：不同生产厂家的FC设备不一定完全兼容

五、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网络，开销为：

14字节(以太网帧头) 20字节（IP头） 20字节（TCP头） =54字节，或者把TCP帧头变为UDP（8字节）一共是42字节

而FC协议就24字节，所以开销比TCP/IP的要小。

网络层

FC网络中的节点要通信，无非也就是连、找、发三大要素。

• 连：通过FC交换机打通通路，主要的拓扑结构有FC-AL和Fabric两种。
• 找：FC协议有一套于以太网不相同的编址方式，可以尽可能减少人为的干预。
• 发：指的是与目标进行通信

从这个方面基本上就可以了解FC各节点交互的流程了。

连：拓扑

与以太网类似，FC也有两种拓扑：FC-AL和Fabric

• FC-AL：类似以太网共享总线拓扑，但是连接方式不是总线，而是仲裁环（Arbitral loop）。每个FC -AL 设备首尾接成了一个环路。最多能接入128个节点，实际上只用了8位的寻址容量。被广播地址、专用地址占用之后，只剩下127个实际可用的地址。

仲裁环是应该 由所有设备串联而成的闭合环路，每个接口上都有一套旁路电路（Bypass Circuit）,一旦检测到本地设备故障，就会自动将这个接口短路。

一跳一跳的传输，而且任何时候只能按照一个方向向下游传输。

• Fabric：与以太网交换拓扑类似。Fabric的意思是“网状构造”，表明其实是一种网状的交换矩阵

相对于仲裁环路来说转发效率提升了很多，联入矩阵所有节点可以同时进行点对点通信，加上包交换所带来的并发和资源充分利用，可使得交换架构获得的总带宽为所有端口带宽之和。

而AL架构下，不管接入的节点有多少，带宽为恒定，即共享环路带宽。

下图为交换矩阵的示意图。

FC终端设备接入矩阵端点，一个设备发给另一个设备数据帧被交换矩阵收到后，矩阵会拨动交叉处的开关，连通电路，传输数据。所以可以把交换矩阵是一个大的电路开关矩阵，根据通信的源和目的决定波动哪些开关。

FC交换拓扑寻址容量是2的24次方个地址，比以太网理论值（2的48次方）少，但是对于专用的存储网足够。

找：编址

任何网络都需要寻址机制，所以需要对FC网络的每个设备定义一个唯一的标识。

• WWNN（World Wide Node Name）：每个设备自身有一个WWNN
• WWPN(World Wide Port Name)：FC设备的每个端口都一个WWPN，是世界上唯一的。

以太网交换设备的端口不需要有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三个亚寻址单元

• 高8位定义为Domain区分符，用来区分网络中的FC交换机本身。Domain ID是自主交换机分配的。那主交换机怎么来的？它是根据WWNN号来进行选举，WWNN最小者获胜，成为主交换机，它就有资格向其他交换机分配Domain ID
• 中8位定义为Area区分符，区分同一台交换机的不同端口组。如果一块芯片可以管理1、2、3、4号FC端口，那么芯片可以属于一个Area
• 低8位定义为Port区分符，区分不同的Port

发：地址映射过程

如下的讲解主要是针对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，万事俱备，完全可以与其他节点进行通信了。

• 首先需要直接向目的端口发起一个N_PORT Login过程，目的协商一系列的参数
• 然后进行Process Login过程（类似TCP向端口发送握手包），即进行应用程序间的通信。比如FC可以承载SCSI协议，那么此时Initiator端就需要向Target端发起请求了。
• 这些Login过程其实就是上三层的内容，属于会话层。但是Login帧也必须通过下4层来封装并传输到目的地，就像TCP握手一样。

FC网络中还有一中FC Control Service，如果节点向这个服务进行注册了以后，一旦网络状态有变动，将会把最新的信息同步到这些节点。

最后一点

上面提到的名称服务器、注册服务器其实一般都是运行在交换机内部的，而不是物理上的服务器。

传输层

FC协议的传输层的作用与TCP相似，也也进行Segment以及通过端口号区分上层应用。

• 对上层数据流进行Segment。
• 每个Exchange（上层程序）发来的数据包，被FC传输层分割为Information Unit，类似于TCP的Segment。
• 然后下层协议为每个Segment分配一个Sequence ID，再分割为FC所适应的帧
• 区分上层程序。TCP是通过端口号，而FC协议是通过Exchange ID来区分。

FC适配器

要构建一个完整的FC网络，除了需要FC交换机，还需要FC适配器(FC HBA,Host Bus Adapter)

HBA可以指代任何一种设备，只要这个设备的作用是将一个外部功能接入主机总线，所以PCIE网卡、声卡和显卡都可以叫HBA。

下图是用来接入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交换机来扩充端口。而且采用了这样的包交换架构，可以实现多个节点向一个节点收发数据，传输效率大大提升。

这样就实现了多台主机共享一个盘阵，提升了盘阵的利用率。

• 而且因为可以使用光纤，所以传输距离加长了。
• FC协议功能更为丰富，可以为每台主机划分不同的LUN，保证了安全性。
• 既然所有的主机都挂在了盘阵上，怎么保证每台主机能独享一块LUN呢？可以从FC交换机，磁盘阵列控制器入手。
• 在磁盘控制器上做手脚：
• 在SCSI协议中有这样一个过程，此时Initiator想要与Target要进行通信，Initiator需要发一条Report LUN指令给Target，Target端在收到这条指令以后，需要返回自己的LUN信息。那么磁盘控制器可以 LUN的时候，根据发起端的身份，提供相应的LUN给它。如果强行访问其他的LUN，就会拒绝。这种方法就叫LUN masking
• 总的来说，可以把LUN当做蛋糕，磁盘控制器就是主人，他可以调查每个主机的身份，根据不同的身份来分配蛋糕。
• 注意，这是SCSI指令集的功能，只要承载了SCSI指令集的协议就可以实现这个功能。
• 在FC交换机上做手脚：
• 我们知道以太网交换机可以划分VLAN，也就是可以把某几个端口划分到一个逻辑上的LAN中。同样FC交换机也可以实现类似的功能，不过名字叫ZONE。
• ZONE有软ZONE和硬ZONE之分。
• 软ZONE：在名称服务器上做手脚，欺骗进行名称注册的节点，向他们通告其他节点信息。
• 硬ZONE：把交换机某端口归为一个ZONE，底层完全隔离。如下

多路径访问目标

如果盘阵有两个控制器，每个主机上都有两块FC适配卡，它们都连接到了FC交换机。

这样会存在一个问题，因为主机有两块HBA卡，而每块HBA可以识别两块LUN，所以整个主机会识别出4块磁盘，这就有问题了，因为这样磁盘就有重复了，造成了混乱。

那么你可能会说，为啥要两块FC HBA卡呢？因为一块HBA有单点故障，如果使用两块HBA卡，一旦一块HBA卡出现了故障，另一块卡依然可以维持主机到盘阵的通路。

那多路径的问题怎么解决：可以在操作系统中安装多路径软件，它可以识别FC提交上来的LUN，向操作系统提交单份LUN。这个软件还有个作用，如果某个控制器发生故障，通过这个软件立即重定向到另一个控制器。

参考,