 |
一、误操作类
误删除、误格式化、误分区、误克隆等；
二、破坏类
病毒分区表破坏、病毒FAT、BOOT区破坏、病毒引起的部
分DATA区破坏；
三、软件破坏类
Format、 Fdisk、 IBM-DM、PartitionMagic、 Ghost等(注！冲零或低级格式化后的硬盘将无法修复数据）；
四、硬件故障类
0磁道损坏、硬盘逻辑锁、操作时断电、硬盘芯片烧毁、软盘/光盘/硬盘无法读盘；磁盘阵列崩溃,数据库损坏
五、加密解密
Zip、 Rar、 Office文档、windows2000/XP系统密码。
六、数据修复时间： 软件故障数据恢复 1~5小时 硬件故障数据恢复 1天~2天 硬盘开盘数据恢复 1天~3天 服务器数据恢复2小时~3天 RAID0数据恢复 2小时~3天 RAID5数据恢复 2小时~3天 磁盘阵列柜数据恢复 2小时~3天
|
 |
|
 |
|
|
 |
 |
| 文件系统基础知识（三）-亿嘉湖南数据恢复基础《九》 | | 出处：ChinaUnix.net 加入时间：2007-04-03 | | <SPAN style="FONT-SIZE: 13px"><FONT color=green> 分布式文件系统向用户提供和本地文件系统相同的访问接口，却可以让用户访问和管理远程的数据。分布式文件系统中的应用可能来自很多不同的节点，它所管理的数据也可能存储在不同的节点上，同时系统中可能存在多个提供元数据操作的元数据服务器，这些都视具体实现而定。分布式文件系统中有很多设计和实现与本地文件系统存在巨大的差别，也是巨大的挑战，这主要是数据、管理的物理分布和逻辑分布造成的。下面主要讲述分布式文件系统设计和实现中所要面对和解决的主要问题。 <BR>4.1 全局名字空间（Global Name Space）<BR> 全 局名字空间是指每一个文件和目录在文件系统中都有一个统一的、唯一的名字，在所有的应用服务器上，用户都可以用相同的名字来访问该文件或者目录而无需关心文件的实际存储位置和给其提供服务的元数据服务器的位置。当用户访问的文件从一个存储位置迁徙到另一个新的位置以后，用户也无需知道。他可以继续用原来的名字来访问此文件或者目录。<BR> 全局名字空间在只有一个元数据服务器的分布式文件系统中比较容易实现，因为所有的名字服务都是由一个服务器提供，它具有全局知识，可以了解和管理全局所有的数据，其中包括名字的组织、映射和查找。整个系统只有一个元数据服务器的分布式文件系统实现有Lustre、CXFS等。虽然它们的系统中还有一个备份的元数据服务器，但是正常时却只有一个元数据服务器工作。当然这样的实现可能存在系统瓶颈，特别是元数据处理比较频繁的时候。所以Lustre、CXFS都在研究如何实现多个元数据服务器协同工作。Storage Tank已经实现了这一点。它将整个文件系统划分成多个文件集（fileset），一般是一个目录及其包含的所有文件和子目录构成一个文件集。整个文件系统可以有多个文件集合，文件集可以嵌套。文件集是一个相对独立的整体，可以独立地进行备份、操作等。Storage Tank中一个文件集只能由一个元数据服务器提供服务和管理。多个文件集可以映射到元数据服务器，共同组成一个全局名字空间。文件集和元数据服务器的映射关系由管理员指定。由多个元数据服务器协同提供名字服务和元数据服务，可以有效地进行负载平衡，也可以提高整个系统的可用性。因为一个服务器的失效不会影响其他服务器的运行，因此除了已经失效的服务器所负责的那一部分系统还可以部分对外提供服务。 <BR>4.2 缓存一致性（Cache Coherence）<BR> 缓存一致性是指在各个应用服务器访问分布式文件系统时，它们所访问的文件和目录内容之间的一致性关系。按照POSIX语义的标准，在本地文件系统中，如果一个进程修改了某个文件或者目录的属性或者内容，其他进程可以在这之后马上察觉到这种改变。但是在分布式系统，要实现严格的POSIX是非常困难的，同时也会导致性能急剧下降。因为用来同步文件属性和内容的开销不仅会消耗计算和网络资源，也会造成很大的延时。因此各种分布式文件系统都或多或少的降低POSIX语义的严格性。 <BR> NFS客户端会缓存文件或者目录的属性信息，并且保持一定的时间。它没有缓存文件的数据。只有在下次访问该文件或者目录的属性，并且时间间隔已经到期的情况下，NFS客户端才会去向服务器端重新刷新这些属性。对于文件或者目录的某些信息，比如文件的访问时间（AccessTime），NFS不会在文件每次被访问时候都去向服务器更新。因为这样会大大增加客户端和服务器之间的通信量和通信延时。GPFS也没有保证文件的访问时间的POSIX语义。 <BR> 在AFS服务器会记录客户端的缓存行为，客户端缓存文件的属性和数据。当有其他客户端试图修改已经被别的客户端缓存的文件属性或者数据时，服务器会采用回调（call-back）的机制通知客户端这些缓存已经失效。 <BR> 分布式文件系统对客户端的写操作一般采用两种方式处理：写回（write-back）和写透（write-through） 。前者缓存客户端写的数据，然后在适当的时候再写回到数据实际应该存储的物理位置；后者是在用户发出写请求时，直接将数据写到该写的地方，然后才将控制返回。前者的好处在于可能减少数据的实际传输量。因为基于数据访问局部性的现象，最近被访问的数据很可能在不久的将来被再次访问。有些文件可能是临时文件，写入以后不久可能就会被删除，有些文件在写入以后，很可能马上就被再次修改。不过这样的方式，很可能影响其它也在同时读该文件的其他主机上的进程，因为它们难以读到最新的数据。 <BR> 同时为了支持客户端对文件加锁的操作，一般有两种处理方式：集中锁和分布式锁。如果一个分布式文件系统中只有一个锁管理器，就称之为集中锁。如果有多个管理器，就称之为分布式锁。集中锁的好处是实现相对容易，不足之处就是效率相对低下，而且一旦锁管理器失效，整个系统使用锁的服务都会被迫停止，直到锁管理器恢复正常运行。按照文件锁的粒度，一般有如下三种层次：整个文件、文件的一段（segment）、文件的任何一部分。第二种是将文件按照某个特定的大小分成多个段，锁的粒度只能是一个段或者是多个段。第三种情况下，用户可以对文件的任何部分加锁，甚至是现在文件中不存在的部分，比如锁的范围已经超出了文件的大小。这三个层次的锁设计和实现难度依次升高，但应用程序对锁的冲突访问的发生则依次降低，从而应用程序访问文件系统的并发度可以依次提高。关于这些锁的赋予和撤销，在[25]中有详细研究。 <BR>4.3 安全性<BR> 在传统的分布式文件系统里边，所有关于文件的数据和元数据都要经过元数据系统进行存取。因此系统的安全性都可以在元数据器服务器那里集中控制。这样的情况下，安全性比较容易实现，一般采用简单的身份验证和访问授权的形式即可，比如NFS、CIFS等。 <BR> 如果应用服务器可以直接访问存储设备，那么系统设计就需要一定的改变来确保所有数据的安全存取。NASD[26]通过在设备上添加一定的软件，利用设备本身的处理能力对用户的请求进行验证。用户在第一次访问某个文件的数据时，由元数据服务器对其进行身份验证和授权，之后通过特定的访问接口和磁盘设备进行交互以达到有限制地访问数据的目的。 <BR> Lustre 采用多种方式来实现系统中文件的安全访问。比如在一个可以信任的域内，采用简单的基于用户ID和组ID的形式，也可以再加入一定的身份验证。Lustre还采用给数据加密的方式保护数据。由于Lustre采用基于对象的存储，凭借对象存储对于安全的控制也能很好的控制系统的安全。 <BR> 现在越来越多的分布式文件系统采用SAN作为其存储环境。SAN的直接磁盘访问方式也给系统的安全实现带来了很大的挑战。Storage Tank 利用系统中的一个可以信赖的验证服务器，采用了独特的“着色＋色彩”的模型，实现了分布式文件系统的数据安全[25]。在此模型中，磁盘设备无需跟验证服务器进行任何的信息交互，只需要对应用服务器提供的“票据”进行验证，简化了磁盘的设计和实现。同时这种方法跟具体的应用环境无关，可以在分布式文件中使用，也可以在电子图书馆等使用共享存储设备（share-disk）的地方发挥作用。<BR>4.4 可用性<BR> 分布式文件系统一般都是由多个节点组成，需要集体协作才能对外提供服务。但是随着系统规模的逐渐扩大，系统中软硬件的失效概率也会大大增加，比如磁盘损坏，节点失效，网络断开等。一般采用RAID技术保证磁盘的有效工作，提供比较稳定的数据源。对于节点的失效，一般针对不同的节点类型有不同的处理方法：对于元数据服务器，一般采用失效接替减少系统暂停服务的时间（比如Lustre、Storage Tank等），采用日志技术进行文件系统的快速恢复（CXFS等）；对于系统中的存储节点，采用数据复制技术（replica），或者采用类似RAID在各个存储服务器之间做数据冗余存储等；对于网络失效，采取把网络划分成多个互相不同通信的几个部分，如GPFS、Storage Tank规定只有包含半数以上可用节点的部分才能继续工作，以避免造成数据不一致性。 <BR>4.5 可扩展性<BR> 应用对分布式文件系统在性能和容量方面的要求在不断的增长。分布式文件系统一般都是通过扩充系统规模来取得更好的性能和更大的容量。但是对于各种系统结构，系统在规模上可能存在不同限制。比如NFS或者CIFS采用单个服务器，那么整个系统的性能和容量都存在瓶颈，难以突破单个服务器系统的极限。于是Slice File System通过在客户机和服务器之间添加μproxy提供系统性能，Zebra通过管理多个存储设备获得更大的容量，Storage Tank、TotalStorage里的元数据服务器集群帮助系统可以动态添加更多的存储设备，服务于更多的客户端文件访问。设法保证系统的性能随着系统的规模能够线性增长，是分布式文件系统一直努力的目标。 <BR> 另外一方面，扩展性还体现在系统规模的增长不会带来系统管理复杂度的过度增加。降低控制系统的管理成本，简化系统的管理流程，都是分布式文件系统实现的关键技术。Storage Tank、CXFS、GFS等将系统分为多个层次，每个层次实现不同的功能，简化整个系统的设计和管理难度。其中很重要的一个技术方面就是存储空间的虚拟化（Virtualization） 。虚拟化存储提供给文件系统的是一个共享的虚拟存储空间，屏蔽了存储实现的细节，同时具备了比如容错、动态负载平衡等特点。分布式文件系统通过利用这些特性，就可以取得很好的扩展性。 <BR>4.6 其他关键技术<BR> 此外，文件系统的快照和备份技术、热点文件处理技术、元数据集群的负载平衡技术、分布式文件系统的日志技术[42]等，都是目前分布式文件系统中需要解决的技术难点。</FONT></SPAN> | | 返回列表 | | | 上一篇： | | 下一篇： |  打印此页  关闭此页 |
|
|
|
