EMCCentera内容寻址存储解决方案介绍资料.doc

EMC Centera 内容寻址存储解决方案

目录

第一章：前言 3
第二章：介绍 4
产品介绍 4
使用Centera 4
C-ClipTM功能 5
Centera结构 6
API 介绍 9
API基本功能 10
容灾技术 12
综述 12
正常操作 (normal operation) 13
修复 (repair and recovery) 13
恢复 (restore) 14
容灾方案的设计需考虑的因素 15

第一章：前言

根据Global 2000 最近的一份调查显示，今后增长最快的数据是一种叫做“固定内容”的数据。固定内容包括了任何形式的数字化信息，如文档、电子邮件、影像、Video/Audio流体、X光片、CAD图纸等。

这种快速增长的数据要求有一个切实可行的存储来实现安全的、在线的、几十年的数据存放——即内容寻址存储(CAS: Content Addressed Storage)。不象传统的通过一个具体的物理地址和文件名来存取数据，CAS设备使用一个内容地址来存放和读取此内容对象。因为一个内容数据通常其大小是没有任何上限的，因此CAS设备需要具有极强的可扩展能力，甚至到PB级(1PB=1024TB)，但同时要保障秒级的寻址性能。

基于BLOCK(块)和文件(FILE)存取的传统的磁盘存储系统，非常适合于那种TB级的、交易型的或整合型的应用环境。但是在今天，我们的管理层需要一个可以在线保存大量固定内容数据系统，这个系统可以通过网络的方式来实现数据的存取。EMC的Centera，是一个基于内容寻址的存储解决方案。它的CentraStar软件，和模块化的磁盘组件一起，共同实现了对应用和用户透明的物理资源的管理。业界的一些内容管理(Content Management)应用可方便地通过Centera所提供的API接口来实现对内容数据的管理。

第二章：介绍
EMC的Centera提供给用户许多独特的价值：

! 容易管理：
Centera技术简化了对几百TB甚至PB的内容数据的管理工作。它无需进行任何RAID的选择，无需进行LUN的配置，无需进行文件系统的管理。用户的应用从传统的提出要求到简单地利用其功能。
! 数据安全
任何呈现给系统的对象，保存在一个不可更改的和需授权的地方。这对用户的应用完全透明。
! 有效的复制
Centera使用一个唯一的基于内容的地址，来确保无论此数据被存入了多少次，它在系统中仅存在一份(和另一份复制数据以保障数据的安全性)。这可有效地减少由于数据的重复存放而造成的整体费用增高。
! 灵活的扩展能力
基于独立节点冗余阵列(RAIN：Redundant Array of Independent Nodes)的Centera可以无需重新配置而进行从TB级到PB级的扩容。
! 容易安装和升级
Centera可在一个小时之内进行在线的系统安装和升级，非常迅速。

产品介绍
使用Centera
Centera介绍了一个新的数据处理技术，即内容寻址。当存放一个固定内容数据到Centera时，应用将获得跟此内容数据对应的唯一密钥(claim check)。

当需要读取此数据对象时，应用可简单地发送它的密钥(claim check)给Centera。Centera接收到此密钥后，就可把对应的数据对象返回应用。

以下图示说明了Centera存放数据对象，亦称之为BLOB(二进制大对象)的详细流程：

1、 应用写入一个数据给Centera API，API计算出一个128位的用户文件内容地址CA，同时产生一些必要的其它数据Metadata，如文件名、生成日期等。
2、 Centera存放此BLOB，同时产生一个镜像拷贝。
3、 CA和Metadata插入一个XML文件，组成一个C-Clip描述文件(CDF)。说明：C-Clip是CDF和内容对象的联合体。
4、 当两份BLOB和两份CDF都被安全地存放在Centera后，C-Clip CA将被返回给应用。
5、 当将来需要使用此对象数据时，应用仅需把此C-Clip CA发送到API，就将从Centera获得此数据，而无需任何其它的目录、文件名、URL地址等。
C-ClipTM功能
C-Clip CA实际上就是存放对象(如用户文件BLOB)的授权指纹。只要是所存的对象有1个Bit被改变，用户应用都将通过API获得一个包含新内容地址的CDF。原来的数据对象仍然使用原有的内容地址和CDF。这种WORM(写一次，读多次)的结构是任何其它文件系统所不能提供的。

另一个好处就是，如果多个用户存放同一个对象数据时，只有一份数据(加上镜像保护数据)将被存放，用户都将获得一个唯一的C-Clip CA指向同一个对象，而不会被存放多份。这对于节省存储空间非常有用，可用于诸如保存EMAIL附件的一些应用中。

这种C-Clip方式，使用应用开发者、用户和存储管理者不需要考虑这些数据的物理存放地址，及逻辑路径。而C-Clip CA是数据的唯一的、全局的、可在任一地点进行存取的标志。

因为Centera使用了一个与物理地址无关的数据存放技术，因此所导致的结果是数据的移动非常简单，可利用此特点进行容灾保护。当一个数据对象被存放在本地时，可同步地、自动地通过WAN复制到异地。这可通过Centera的软件功能实现，在实施时同时配置好本地的和异地的Centera即可。

当本地发生灾难，需要重建数据时，异地的Centera可根据需要当成本地的Centera使用。同时，这种数据复制是可以双向的。

用户使用Centera时，是通过基于内容的软件应用(例如Content Management应用)实现。此内容管理软件通过Centera强大的API功能访问Centera。
Centera结构
Centera是一个“无单点故障”的结构，它具有极强的可扩展性和非中断实施能力。Centera由冗余阵列独立节点(RAIN)组成，可安装在一个或多个19’’机架上。一个独立的机架可安装16、24或32个独立节点，对应地提供4.2TB、7.2TB或9.6TB被镜像保护后的可用容量。每个节点包含有一个CPU，600GB物理容量，同时通过一个自带的局域网（Private LAN）连接到同族(cluster)中的其它节点。每个节点可操作在如下二种模式：

1) 存储节点(Storage Node)：用于长期存放BLOB和CDF
2) 前端节点(Front-End Node)：用于连接应用服务器和存储节点

吞吐量性能由安装时配置了多少个前端节点来决定。每一个前端节点通过一条100MB的以太网线连接到应用服务器。提供的Centera可以通过多条网线连接到应用服务器。应用服务器完全可享受由Centera所提供的灵活扩展能力和高可用性。

需注意的是，前端节点并不提供长期的数据存放，存储容量的计算由存储节点来决定。例如，一个32节点的Centera，若配置4个节点为前端节点，28个节点为存储节点时，则可用的容量为：28 * 600GB / 2 = 8.4TB。

这种结构使得Centera具有容量和性能的极佳可扩展能力。容量扩展可通过一次加入2.4TB可用容量的节点(即8个存储节点)实现。同时，通过前端节点的扩展，可满足性能的要求。

这种结构最大的好处是，扩展非常简单，无需增加时间，无需复杂的管理。这种结构使得一个管理员就可以轻松管理几百TB或PB的数据。

多个Centera机架可以组合成一个单独的族(cluster)，提供154TB的可用容量。Centera通过多条TCPIP LAN端口连接多台Windows或Unix应用服务器。如果154TB还不够时，用户端应用API可以同时涉及几个族(cluster)，如下图所示，以达到PB级的容量。实施时非常简单，就是简单地把新的族连接到应用服务器的LAN即可。Centera的API已设计成可处理多个族的并行结构。

Centera机架可由二路不同的外部电源供电，以提高可用性。同时，可保证保存在Centera中的镜像数据由不同的外部电源供电。如果外部电源A掉电后，存放在另一个节点的数据可由外部电源B(未掉电)继续访问。

注意，当二个外部电源中的一个掉电后，Centera则处于一个“只读”状态，这是因为此时新写入的数据不能进行镜像复制的原因。因此，对于高可用性要求的用户来说，采用一个UPS进行电源保护，可保障数据的连续可用。

Centera本身具备许多的管理功能，使得用户无需对它进行更复杂的管理，因此可大大降低整体运行成本。例如Centera本身具备有自我管理功能、动态扩展能力、自治愈能力。当一个新的存储单元加入到一个族(cluster)中，通电后，Centera就可自动地“自动发现”，同时把此新存储单元加入到此族中。

利用Centera的操作软件：CentraStarTM，当一个磁盘故障时，受这个故障磁盘影响的所有对象数据将由另外的可用磁盘自动重建。在一个硬件故障的事件中，用户数据可保障任何时候都可用，无需进行任何停机或恢复的动作。另外，数据的一致检查都是在后台进行，它连续计算所有对象的内容地址，并与原来存储在CDF中的内容地址进行比较。同样地，镜像的对象同样进行类似的确认。

Centera的安全模式设计是基于C-Clips固有的特性的，是一个集成的技术。基本的存取控制就是，如果你不知道BLOB的C-Clip CA，则无法访问Centera中的此数据对象。

管理Centera的操作是非常简单易行，具有长期的生命周期。Centera软件CentraStar，可进行对存储数据的写入、读取和智能的网络认识。它提供Centera强大的功能，如自我管理、自我配置、自我治愈、非中断维护和升级、和内容复制功能。另外决定和指定每一个存入对象唯一地址的软件技术同时也是CentraStar的一部分。

Centera的内容寻址特性使得可简便地扩展容量，同时也使得存放的对象可方便地在用户的内容构架中进行移动。这个内容地址，数据对象的唯一标志，确保所需信息的授权，因此无论在何时何地都可访问此对象。存取对象时不要求任何对存储环境，或对象存放物理地址的知识。而这些关系是由CentraStar操作环境来维护的。

系统管理员无需担心对卷和文件系统结构的维护。系统管理员需要做的是监控Centera的容量和对象存放/读取的性能(MBps)。系统管理员从任何一台通过LAN连接到Centera前端节点的Windows PC或UNIX工作站，用一个简单的CLI，通过SecureShell(ssh)来远程管理Centera。这个CLI同时允许系统管理员用来改变任何跟节点有关的信息，如Centera的公共IP地址和子网，及用户联系名字和EMAIL地址等。

如前面所述，在需要增加容量时，若在同一个机架中有空的位置，则简单地安装新的存储节点即可；若是需要增加另一个机架，则通过2个千兆以太网LAN连接此两个机架即可，是真正的“即插即用”设计。

API 介绍
如前所述，应用服务器存取Centera时是通过API来实现的。而一个CDF是所需数据对象的XML描述文件，它不但包含了指向此数据对象的地址指针，还包含有系统产生的其它数据，如系统名、定位、产生者、项目名等。

一个基于内容的应用将使用一个数据库来管理此对象的“所有者”、影像、文件等信息。这个数据库将按分类号或记录号来索引，也包含有指向数据对象的域。这样的数据适应Centera的API结合，我们只需非常简单地用C-Clip库中的内容地址代替数据库的对象指针域。例如，当一个用户的保单影像被存放时，它的C-Clip CA会被插入此内容管理应用数据库中与此保单对应的域。当需要调用此保单时，应用简单地使用此C-Clip CA来获得此保单影像文件。

CDF另一个特性是，它能通过使用XML tag来存放每个存入对象时应用所产生的其它信息。每个tag都有一个应用程序定义的专用名字，同时可有一个或多个属性。例如，假设Centera用来存放保单影像文件时，CDF不但有此保单的内容地址，还可包含有此保单的被保险人名等信息。

另一个说明Centera可节省空间的例子就是，如果有25个人同时收到带几十个MB的电子邮件附件时，在Centera将只仅仅保留一份此附件(镜像保护)，但有25个CDF同时指向此附件对象。
API基本功能
有四种基本的API功能：store (写)、retrieve (读)、exists (是否存在)、delete (删除)。Store和Retrieve是自解释执行，也是最常用到的API功能。Exists是应用程序用来检查某一对象是否已经存在于Centera中。如果一个对象已经存在，则完全没有必要再浪费时间和网络资源来进行第二次存放，这尤其当此对象非常巨大时，效果更为明显。

第二次企图存入同一个对象时，系统将简单地产生针对不同应用的第二个CDF。Delete则至少有二个重要功能：一个是应用可能需要删除一个必须删去的对象；另一种情形是这个对象可能存放时间超过所需要求。

EMC提供了一个可选的软件开发包，来允许应用开发人员进行适当的开发工作。最快地和最简单地使用API的方法是利用高级toolbox功能，它可允许快速和方便地修改应用来执行基本的写和读功能。Toolbox允许用一个单一的ANSI C函数来完成，而无须调用那些复杂的API语句。

另一个更为强大、更为复杂的API利用就是使用一些低级的API调用。这种方法允许应用来访问Centera的pool,clip和tag。

Pool级的功能包括了打开(open)一个与Centera群集的连接(“FPPool”)，以允许存放或读取一个对象。当存放一个对象时，应用程序将产生一个新的、空的C-Clip结构(“FPClip”)，紧跟着打开(opening)和建立(creation)一个tag (“FPTag”)。这个对象然后将通过FPWrite功能被存放在Centera中，Centera则返回此对象的C-Clip CA给应用。应用程序然后关闭此C-Clip来终止本次写操作，跟着再关闭此pool。

上述是一个写操作的例子。应用开发人员可以使用大量的API，同时需要处理这些API的返回值。低级的API可在ANSI C和JAVA环境下实现。

Centera的API在WindowsNT/2k平台下是DLL，在Solarix、Linux、HP-UX和AIX平台下是一个二进制文件。

容灾技术
综述
容灾技术即是Centera对数据复制能力的具体体现。而Centera的复制技术即是自动地把新存入的数据拷贝到另一个cluster。当一个Centera cluster从本地应用服务器接收到一个新的内容数据时，“复制”机制能确保此数据能对应用透明地自动地通过WAN传输到另一个地方的Centera cluster。

在一个典型的复制计划，Centera cluster可进行全球范围的放置，进行数据的复制。例如，企业可在利用复制技术，来避免不同点访问同一数据时对WAN的资源要求。

不象EMC的SRDF数据同步镜像复制那样，Centera的复制技术是一种异步的数据复制。当一个新的数据对象到达本地的cluster时，它所对应的C-Clip ID排列放入一个固定的log中，以便进行复制准备。这个C-Clip ID在复制到另一个cluster之前，都一直保存在此队列中。

恢复操作类似于复制操作。但不同点是，复制操作是一种连续不断的操作，而恢复操作是根据具体要求进行的。一旦从备份点同步了所有的数据到本地，此恢复操作则完成。

由于复制的异步特性，在考虑cluster和WAN时必须要适应应用程序的写入率。如果cluster没有配置成满足应用写入数据的性能要求，则复制处理过程将滞后于应用服务器对数据处理的过程。滞后时间越长，发生灾难时数据丢失的风险也越大。

当写入一个文件到本地的cluster时，它同时也被放到复制队列中。在任何时候当本地端和异地端的WAN连接中断时，复制处理也暂时停止了。一旦恢复WAN连接，复制操作将从WAN中断点继续进行。当远程端已包含了相同的C-Clip ID时，对应的数据对象就并不会被重复复制，以避免重复的数据存放在同一个cluster中。

以下以典型的三类数据复制环境来阐述Centera的容灾技术：
1、 正常操作。数据复制按计划运作正常
2、 修复操作。当原来的cluster由于故障或容难原因导致不可用时
3、 恢复操作。当修复操作结束后，数据恢复到原来的cluster
正常操作 (normal operation)

Centera的复制可配置成几种方式，以下仅以单向复制为例。

在一个单向复制的操作中，应用A连接到Centera cluster 1。应用服务器连接到cluster 1 来存取内容对象。此时cluster 1存放对象同时排列所有的已存放对象用于复制到cluster 2 (参考上图)。在一个WAN断接，或丢失复制cluster事件时，在cluster 1中继续可进行对象存取，同时它的复制队列继续运行。我们不应担心此队列增长时其存放空间会不够。Centera完全可满足对象满存的情形。

也可能有应用B来协作激活cluster 2来保证当应用A和cluster 1不可用时的替换。在这种情形下，应用服务器的数据库应当在A和B两点保持同步，例如可采用SRDF来实现。
修复 (repair and recovery)
如果外部电源掉电，或网络故障发生，应用服务器不能从cluster 1 读写数据对象，那么应用服务器将收到一个错误信息表明此cluster不可用。

在cluster 1由于一个事故，或一个容难导致数据丢失时，则与应用A丢失的情形一样处理。如果应用A或cluster 1不可用时，而此时在复制端的应用B可用时，则应用B是激活状态，可继续访问cluster 2。

但当在cluster 1不可用，而应用A可用时，应用A可连接到cluster 2来继续读写数据对象。这可通过自动化的规则导向，或通过系统操作员的人式干预来实现。

另一个情形就是，应用A和cluster 1都在一个容难事件中完全被破坏。应用A通过备份服务器重建数据。当应用A重建后，它再连到cluster 2 (参考下图)。那么如果应用A在cluster 1找不到数据对象时，它将自动进行fail-over(切换)到cluster 2的读操作，但写和删除操作不能自动切换，这是因为原来的系统构架成一个容灾的系统，此时写和删除操作并不能进行复制而达到容灾目的。

如果cluster 1在一次灾难事件中完全丢失所有数据，则此内容是不可修复的。如果在 cluster 1中有数据未被复制到cluster 2，则此时进行修复时，这部分数据应用A不可以访问。当应用A连接到cluster 1后，这些数据可立即可访问。
恢复 (restore)
当cluster 1被修复后，那些以前从cluster 1复制到cluster 2的数据，加上应用A此时在cluster 2中新存放的数据，可被恢复到cluster 1。这个恢复操作是通过Centera的系统操作CLI来实现的。

当应用A连到cluster 1后，就可立即开始正常的进行写和读的操作(参考下图)。如果应用A此时需要读的数据对象此时还未从cluster 2恢复过来，则应用A可自动地切换到cluster 2进行读操作。

如果cluster 1用一台新的cluster更换，则所有的cluster 2数据将全部恢复到新的cluster 1。

容灾方案的设计需考虑的因素
当进行一个容灾方案的设计时，需要考虑以下的几个方面，具体内容请参考附录。

! 数据复制是单向的，还是双向的。
! 本地的写和读内容的比率。在一个双向复制配置时，有两个或多个的本地应用服务器，而且至少对每个Centera cluster都有一个应用服务器。
! 应用服务器对cluster的内容写和读的比例。
! 存放的周期。即，应用服务器花了多长时间用于数据存放和读出。
! 需要复制的对象队列的最大长度要求。队列越长，在一次事故中可能丢失的数据量越大。
! WAN所支持的吞吐量。

以上仅简单介绍了Centera的复制技术，具体细节及方案需要与用户在进行方案设计时共同决定。