4. 共享存储
转换系统必须能够访问停机系统正在处理的数据以使它能承担停机系统的工作。这里面蕴涵了如下两个假设:
•转换系统有访问该数据的路径。
•故障发生时中途停止写的数据不会严重影响整个工作。
通过实现支持多启动器，以及能够提供路径控制和管理的I / O访问体系结构，可以实现第一个假设。基于S A N的光纤路径为这种网络提供了极好的选择，此外，由专用的N A S服务器构成的以太网也不错。第1 0章中介绍了光纤路径的一种实现—Cluster Crossover SAN，它能够提供对备用系统的转换连接。
第二个关于不完全写入的假设，可以采用数据库和文件系统技术来解决，这种技术将所有的I / O操作看成事务进行处理。它基于以下思想：无论是文件系统还是数据库，通过扫描记录了所有I / O活动的日志文件，都可以知道是否一次I / O操作已经正确完成。这些日志文件可以被快速读取，以确定应该做哪些工作修复写操作。如果找到了问题所在，那么可以把数据改变回写之前的状态，从而快速纠正错误。
1) 数据库事务提交
数据库系统采用事务提交机制，确定一个事务是否已完成对数据库的所有写操作。对于相当复杂的系统，它在一次事务中要完成多个操作和多处写。数据库开发人员知道，当系统突然崩溃时不完全写操作造成的严重后果。为了解决这个问题，数据库系统在数据库的不同部分之间，使用内部握手协议共同确定是否新的事务已被提交。
数据库系统保存一个事务内每次写操作的日志，如果发生了错误，根据数据库管理员（D B A）的要求重新创建或回退这个过程。D B A的一个主要职责是理解数据库的提交机制，以及发生错误后如何将数据库恢复到一个安全的状态。这种事务回退的过程是关系数据库技术的基石之一。这种技术并不是专为集群发明的，而是任何在事务操作中有可能发生系统崩溃的数据库系统所必需的。有许多关于流行数据库系统的内部体系结构的书，可以用来研究数据库事务机制。
2) 日志和日志结构的文件系统
同样，支持日志的文件系统也提供了识别和修复不完全写的方法。基本的想法是：文件系统维护一个或多个日志文件，跟踪记录文件系统内的写操作状态。例如，日志可以表明新的数据已经写入。本质上，一个支持日志的文件系统有能力回退对文件系统的不完全写。
日志提供了一个近似即时的方法来检查文件系统的完整性。如果没有日志，则需要检查每个目录和文件条目，以确定文件系统的组织数据是否有错误。这个操作可能需要几分钟，对于大型系统甚至可能需要几小时。这种时间耗费显然不是实现集群系统的人们所期望的。正如数据库事务提交控制，日志型文件系统也不是为集群操作发明的，而是为那些需要快速从故障中恢复的单个系统设计的。
另一个相关的文件系统技术是日志结构型文件系统。它的基本思想是把所有的数据写到存储设备或子系统的后面。换而言之，日志即文件系统本身。文件系统的“清理”功能周期性地清除存储系统中的无用数据，并重新组织剩下的数据。换而言之，它在后台进行存储整理工作。
在日志结构型文件系统中，由于新写入的数据总是被放在数据末尾，故而很容易找到最近写入的数据和日志以确定是否存在问题。
3) 数据完整性验证
前面讨论的目的，在于在集群中可以使用软件的方法保证数据完整性。集群的转换过程使用这些方法，验证不完全写的数据不会引起连锁故障。因此，转换系统必须能够访问停机系统工作的日志文件，并且在继续运行之前回退任何不完全写操作。
阅读(470) | 评论(0) | 转发(0) |
