CN103733181A - 系统中的故障处理 - Google Patents

Abstract

提供关于第一子系统的操作的状况指示。检测第一子系统的故障。响应于检测到故障，更新状况指示，并且释放由第一子系统使用的资源。

Description

系统中的故障处理

背景技术

系统能够具有用于执行各种任务的不同子系统。系统的示例包括存储系统、处理系统或其它类型的系统。在系统操作期间，一些子系统可能经历故障，故障会导致该系统中的错误。

附图说明

一些实施例是关于以下附图描述的：

图1和图2是根据各实现方式的示例布置的框图；

图3是根据一些实现方式的处理的流程图；

图4和图5图示根据一些实现方式的示例状况指示；以及

图6是根据一些实现方式的监视子系统的框图。

具体实施方式

系统内的子系统能够提供关于相应子系统的操作的状况指示。“子系统”能够指在物理机器内运行的进程（例如机器可读指令），或者可替代地，“子系统”能够指机器（包括硬件组件和机器可读指令）或该机器的任何部分。在一些示例中，状况指示能够指示子系统的各种状态，如“启动”（子系统正在启动）、运行（子系统目前正在运行）等等（其它示例状态在下面进一步介绍）。

子系统会经历故障（如子系统失效或子系统的组件未正确操作）。当子系统经历故障时，子系统可能不能更新其状况指示，这能够导致在子系统已经经历故障以后状况指示不再准确。由子系统提供的不正确的状况指示能够造成整体系统中的错误。例如，一组子系统可能对有序的或顺序的约束敏感，在该有序的或顺序的约束中，一个这样的子系统的特定操作会在另一子系统的相应操作以后发生（例如一个子系统会在另一子系统已经启动以后启动）。该组子系统可能是一堆子系统的一部分，其中该堆对该堆内的子系统施加有序的或顺序的约束。因此，如果该堆中的第一子系统表示其正在正确地操作（即便第一子系统未正在正确地操作），那么跟随第一子系统后的第二子系统可能基于第一子系统已经成功地完成其操作的不正确假设而不正确地进行第二子系统的操作。作为另一示例，第一子系统可以尝试访问第二子系统，第二子系统的状况指示表示第二子系统正在正常地操作，但是此时实际上第二子系统已经失效。无法访问第二子系统能够造成第一子系统以及整体系统的其它部分处的错误。而且，当特定子系统已经失效但其状况指示表示其正在正常地操作时，由该失效的子系统使用的资源可能继续被分配给该失效的子系统，这使得被分配的资源无法由其它子系统利用。

图1图示根据一些实现方式的示例系统100。该系统能够具有按层次布置的多个子系统。图1所示的多个子系统能够是一个物理机器（例如计算机系统、存储系统、通信系统等）的一部分或者能够是物理机器的分布式布置的一部分。该层次的顶层包括监视子系统102，该层次的中间层包括中间子系统104和106，并且该层次的低层包括子系统108、110、112和114。

尽管图1示出具有三个层次的系统，但应当注意，在其它实现方式中能够采用其它示例布置，这包括仅采用两个层次或多于三个层次的布置。低层子系统108和110与中间子系统104关联（例如低层子系统108和110能够是在中间子系统104中运行的进程）。类似地，低层子系统112和114与中间子系统106关联。

如图1所示，每个子系统包括状态报告模块（在每个子系统中标记为“SRM”），该状态报告模块能够提供相应的状况指示。一些实现方式中的状况指示能够以状态文件的形式，如根据XML（可扩展标记语言）格式或其它格式的文件。

由中间层子系统和低层子系统（104、106、108、110、112、114）中任何子系统的状态报告模块提供的状况指示，能够由监视子系统102监视。在一些示例中，监视子系统102能够提供“监视狗”活动。监视狗活动能够包括对系统中各个子系统的状态进行监视，并且在检测各个子系统中任何子系统中的某故障时，能够执行任务来解决这样的故障。

监视子系统102能够是与实现中间层子系统和低层子系统的机器分离的机器的一部分。可替代地，监视子系统102能够是在与中间层子系统和低层子系统中一个或多个子系统相同的机器上运行的监视进程。

除了中间层子系统和低层子系统的状况指示可由监视子系统102访问以外，应当注意，特定子系统的状况指示也可由与该特定子系统关联的更高层子系统访问。例如，由低层子系统112或114的状态报告模块报告的状况指示可由中间子系统106访问。

监视子系统102还包括能够将状况指示提供给可管理性接口116的状态报告模块，可管理性接口116能够包括用户接口系统（如管理控制台，像管理员这样的用户能够通过该管理控制台确定系统100的各个子系统的状态）。可替代地或此外，可管理性接口116能够包括不同类型的系统，如能够响应于由监视子系统102提供的状况指示而采取自动补救行动的自动化系统。

根据一些实现方式，较高层子系统能够监视较低层子系统的操作，以确定由较低层子系统提供的状况指示是否是准确的。例如，监视子系统102能够间歇性地轮询中间层子系统和低层子系统（104、106、108、110、112和114）中每个子系统，以确定相应的子系统是否可操作。在可替代示例中，代替监视子系统102轮询较低层子系统，能够采用心跳机制，其中较低层子系统间歇性地向监视子系统102发送心跳消息。在预限定的时间间隔内未能收到心跳消息是较低层子系统已经经历故障的指示。能够定期地或根据某些其它准则执行心跳消息的轮询或通信。

在其它实现方式中，代替监视子系统102执行心跳消息的轮询或接收，中间子系统104或106能够执行分别每个低层子系统108、110、112或114的轮询或从各个低层子系统的心跳消息的接收。在这样的实现方式中，正是中间系统能够识别低层子系统的故障状态。

在一些示例中，如果检测到特定子系统的状况指示是不正确的（例如，特定子系统的状况指示表示特定子系统的正常操作，虽然该特定子系统已经经历故障），则能够更新由监视子系统102输出的状况指示来表示已经发生故障。在示例中，由低层子系统108输出的状况指示可以表示正常操作，虽然低层子系统108已经经历故障。表示子系统的“正常操作”的状况指示能够指该子系统正在以期望的方式操作（例如，该子系统正以成功指示对轮询请求做出响应，或者该子系统正以期望的时间间隔发送心跳消息）的指示。当监视子系统102检测低层子系统108的故障状态（如通过上面提到的轮询机制或心跳机制）时，监视子系统102能够更新其状况指示（被输出至可管理性接口116）来反映该故障。

此外，监视子系统102能够更新由故障的低层子系统108输出的状况指示来反映低层子系统108的故障状态。

在其它示例中，当检测低层子系统108的故障状态时，能够更新由中间子系统104报告的状况指示来反映中间子系统104与已经经历故障的低层子系统关联。在一些实现方式中，中间子系统104的状况指示的更新能够由监视子系统102执行。在其它实现方式中，中间子系统104的状况指示能够由中间子系统104自身更新。

图2是另一示例系统200的框图，其能够是根据一些实现方式的存储系统。存储系统200包括应用管理器202以及各个虚拟磁带库（VTL）管理器204和206。此外，能够存在由VTL管理器204和206管理的多个VTL进程，这些VTL进程包括VTL进程208、210、212、214和216。VTL（或虚拟磁带库）能够指数据存储子系统，该数据存储子系统能够利用（磁带存储介质之外的）存储组件来对包括磁带存储介质的磁带库进行虚拟化。VTL能够用多种分离的VTL进程（如图2所示的那些进程）实现。VTL进程是VTL内控制该VTL内的数据传输（在读访问或写访问期间）的进程。各种分离的VTL进程能够模拟物理磁带库以及其相应的行为或任务（注意，VTL进程208、210、212、214和216中不同VTL进程能够模拟不同的物理磁带库行为或任务）。VTL管理器负责管理一个或多个VTL进程——应当注意，VTL管理器不牵涉VTL中的数据传输。

在图2的示例中，VTL管理器204管理VTL进程208和210，而VTL管理器206管理VTL进程212、214和216。在一些示例中，VTL管理器204和关联的VTL进程208和210能够是对应的机器（如存储服务器）的一部分。类似地，VTL管理器206和其VTL进程212、214和216能够是另一对应的机器（如存储服务器）的一部分。在其它示例中，VTL管理器204和206（以及它们各自的VTL进程）能够是相同机器的一部分。

存储系统200还包括盘存储介质220，盘存储介质220能够用一个或多个存储设备（如存储设备的阵列）实现。各个VTL进程能够访问（读或写）盘存储介质220上的数据。

应用管理器202能够执行用于存储系统200的预限定的管理任务。在一些示例中，应用管理器202能够管理客户设备或主设备（图2中未示出）的数据向图2的存储系统200中的盘存储介质220上的“盘到盘”存储。在不同实现方式中，应用管理器202能够执行其它管理任务。

应用管理器202、VTL管理器204和206以及VTL进程208、210、212、214和216被认为是存储系统200的子系统。应用管理器、VTL管理器和VTL进程中每个均能够包括用于报告相应状况指示的状态报告模块（SRM）。存储系统200的各个子系统能够对应于图1所示的各子系统。虽然图2中示出三个层次的子系统，但应当注意，在可替代示例中存储系统200能够包括具有不同数量层次的不同层次管理。

应用管理器202能够将由其状态报告模块生成的状况指示报告至可管理性接口222，可管理性接口222类似于图1的可管理性接口116。

图3是根据一些实现方式的处理的流程图。该处理能够分别在图1或图2的系统100或存储系统200中执行。根据图3，第一子系统提供（在302处）关于第一子系统的操作的状况指示。在图1的情境中，第一子系统能够指中间子系统或低层子系统中的任何子系统。在图2的情境中，第一子系统能够指VTL管理器或VTL进程中的任何管理器或进程。第二子系统检测（在304处）第一子系统的故障。在图1的情境中，第二子系统能够指监视子系统102，在图2的情境中，第二子系统能够指应用管理器202。可替代地，如果第一子系统是低层子系统（例如图1的108、110、112或114，或图2的208、210、212、214或216），则第二子系统能够指中间子系统（例如图1的104或106或图2的204或206）。

响应于检测第一子系统的故障，第二子系统更新（在306处）在系统中提供的状况指示来反映所检测的故障。所更新的状况指示能够是第二子系统（例如监视子系统102或应用管理器202）的状况指示。可替代地，所更新的状况指示能够是比监视子系统更低层的子系统（如图1的中间子系统104或106或者图2的VTL管理器204或206）的状况指示。此外，第二子系统能够更新故障的第一子系统的状况指示，来表示第一子系统的故障状态。

而且，响应于检测第一子系统的故障，图3的进程还释放（在308处）由已经经历故障的第一子系统使用的资源。“释放”资源指对该资源进行解除分配，使得资源不再被标记为分配给特定子系统，使得该资源可被其它子系统利用。释放资源还能够指放弃由特定子系统对该资源的独占访问（例如，特定文件或数据库表的独占访问），使得别的子系统能够访问该资源。所使用的资源的示例能够包括从存储器、文件、硬件设备、软件模块（包括机器可读指令）、数据库连接（包括通信资源和数据库引擎资源）和会话（由向在该会话的通信中涉及的各个实体分配的标识符（如地址）限定）中选择的至少一种。

图4示出能够由图2的存储系统200的各个子系统提供的示例状况指示。在图4中，VTL进程208提供状况指示402，状况指示402能够呈例如XML文件的形式。

在根据图4的示例中，状况指示通常具有根据XML文件400的格式。XML文件400具有多个字段，这些字段包括识别各个子系统的状态的“进程状态(ProcessState)”字段、识别各个子系统的PID（进程标识符）字段、识别各个子系统的健康水平的“健康状况水平（HealthStatusLevel）”字段、表示各个子系统正在如何良好地运行的“健康状况（HealthStatus）”字段以及包含能够由各个子系统输入的文本的“文本（Text）”字段。注意，仅绘出一些字段，因为XML文件400能够包括更多字段。在其它示例中，XML文件400能够包括可替代字段。

在状况指示402中，“进程状态”字段具有值“正在运行（Running）”（表示VTL进程208正在正常运行），PID字段具有值“87”（VTL进程208的进程ID），“健康状况水平”字段具有值“好（OK）”（表示VTL进程208具有可接受的健康水平），“健康状况”字段具有值“联机（Online）”（表示VTL进程208是联机的），并且“文本”字段具有对应的文本。状况指示402的“进程状态”字段能够潜在地具有其它状态，这些状态包括“正在启动（Starting）”（表示子系统正在启动）、“未能启动（Failed to start）”（表示子系统未能启动）、“故障（Fault）”（表示子系统已经经历故障）、“正在停止（Stopping）”（表示子系统正在停止）以及“已停止（Stopped）”（表示子系统已停止）。提供上面的潜在状态来用作示例，因为在其它实现方式中能够使用其它或可替代状态。

“健康状况水平”字段能够具有不同于“好”的程度，如“信息（Information）”（表示各个子系统具有应当由监视子系统检索的信息）、“警报（Warning）”（表示可能存在能够引起故障的问题）以及“危急（Critical）”（表示在报告子系统中或在低层子系统中已经发生故障）。尽管上面提供多个健康水平，但应注意，在其它示例中，能够报告附加的或可替代的健康水平。

“健康状况”字段还能够具有不同于“联机”的值，如“正在运行”（表示各个子系统正在操作）以及“错误（Error）”（表示已经发生故障）。在其它示例中能够使用其它的或可替代的“健康状况”字段值。

在一些实现方式中，“健康状况”字段用于表示各个子系统正在如何良好地执行，而“进程状态”字段用于管理各个子系统的启动和子系统间相依性的关联排序。“进程状态”字段还能够用于监视子系统（例如图1的102或图2的202）的监视。

在其它示例实现方式中，仅“进程状态”字段和“健康状况”字段之一能够出现在状况指示中。

如图4中进一步示出的，能够将由VTL进程208输出的状况指示402提供至VTL管理器204。然后，VTL管理器204输出状况指示404，状况指示404具有用于XML文件400的各个字段的对应值。

将由VTL管理器204输出的状况指示404提供至应用管理器202，然后应用管理器202还输出其各自的状况指示406。能够将状况指示406提供至GUI模块408和/或另一可管理性接口410。在一些示例中，由VTL管理器204输出的状况指示404还能够由GUI模块408接收。因此，GUI模块408能够用来将与各个子系统（作为示例，包括应用管理器202和VTL管理器204）关联的状况指示提供至用户（如管理员）。

图5示出VTL管理器204已经失效的示例。VTL管理器204的失效意味着下面的VTL进程208也已经失效。注意到，在图4的示例中由VTL管理器204输出的状况指示404在图5中还未被更新，即便VTL管理器204已经失效。因此，状况指示404不正确地表示：VTL管理器204的“进程状态”字段具有值“正在运行”，其“健康状况水平”具有值“好”，并且其“健康状况”字段具有值“正在运行”。

应用管理器202能够间歇性地轮询VTL管理器204来确定VTL管理器204是否仍正在运行。可替代地，能够采用心跳机制，其中VTL管理器204将心跳消息间歇性地发送至应用管理器202。在某一预限定的时间间隔以后未能收到心跳消息，代表应当已经发送该心跳消息的组件的失效。

响应于检测VTL管理器204的失效，应用管理器202更新其状况指示406'，来反映其“健康状况水平”是“危急的”并且其“健康状况”是“错误”。注意，状况指示406'的“进程状态”字段仍具有值“正在运行”来反映应用管理器202仍能够成功地运行，即便应用管理器202正在报告其“健康状况水平”是“危急的”并且其“健康状况”是“错误”。

尽管图5中未示出，但应注意，应用管理器202还能够更新状况指示404（前面由失效的VTL管理器204输出的状况指示）来表示VTL管理器204的故障状态。

除了能够响应于检测子系统的故障而更新状况指示以外，根据一些实现方式的监视子系统（如图1中的102或图2中的202）还能够监视由各个子系统使用的资源。由子系统使用的资源能够由监视子系统跟踪（tracked）在各自的资源利用列表中，其中资源利用列表能够与子系统的标识符关联。因此，第一子系统能够与第一资源利用列表关联，第二子系统能够与第二资源利用列表关联，以此类推。每个资源利用列表识别由各个子系统使用的（被分配给各个子系统的）资源（多个资源）。

在一些示例中，资源的跟踪能够牵涉到使用IPC（进程间通信状态）工具、LSOF（列表打开文件）工具、NETSTAT（网络统计信息）工具或任何其它机制（包括特定卖方工具等）。在一些实现方式中，监视子系统能够提供由该监视子系统正在监视的子系统使用的所有资源的聚集查看。当检测特定子系统的故障时，监视子系统能够检索相应的资源利用列表来识别在故障时该特定子系统使用的资源。监视子系统能够释放（图3中的任务308）由该资源利用列表识别的资源，这能够牵涉对前面向该特定子系统分配的任何资源进行解除分配或者放弃资源的独占访问。

当检测子系统的故障时，监视子系统能够实施补救行动。一种这样的补救行动是向诸如用户或自动化实体之类的另一实体提供消息。可替代地，监视子系统能够引起已经经历故障的子系统的重启动。在一些情况中，已经经历故障的子系统实际上也许未失效——该子系统可以继续运行的，但是可能正在故障状态下运行（这里该子系统未正确地操作）。在这样的场景中，监视子系统能够引起故障的子系统的强迫失效，使得能够在该子系统已经实际失效以后采取进一步的补救行动（例如重启动）。

通过能够检测故障的子系统以及响应于检测故障的子系统而采取补救行动，能够在错误在系统中传播以前解决这样的故障。此外，通过能够释放前面向故障的子系统分配的资源，能够使重新分配的资源可用于其它子系统。此外，通过使用监视子系统来释放与故障的子系统关联的资源，该子系统不必需具有用于在该子系统重启动时整理之前分配的资源的代码。

图6是根据一些实现方式的示例监视子系统600的框图。监视子系统600能够被实现为计算机系统，或者能够被实现为计算机系统的分布式布置。监视子系统600包括监视进程602和状态报告模块604。监视进程602能够执行上面介绍的各种任务，这些任务包括例如图3的进程。状态报告模块604用于生成状况指示，如分别在图4或图5示出的状况指示406或406'。

监视进程602和状态报告模块604能够被实现为可在一个或多个处理器606上运行的机器可读指令。处理器能够包括微处理器、微控制器、处理器模块或子系统、可编程的集成电路、可编程的门阵列或者别的控制设备或计算设备。

监视子系统600还包括网络接口608，以允许监视子系统600经由网络通信。此外，监视子系统600包括用于存储各种信息的存储介质（或存储媒介）610，信息包括正由监视子系统600监视的各个子系统使用的资源的列表612。监视子系统600还能够将各种状况指示614（包括由监视子系统600输出的状况指示以及从其它子系统接收的状况指示）存储在存储介质或存储媒介610内。

尽管图6示出监视子系统的组件，但应注意，其它子系统（如图1或图2绘出的那些子系统）能够具有类似布置。

存储介质或存储媒介610能够被实现为一个或多个计算机可读存储介质或机器可读存储介质。存储介质包括不同形式的存储器，包括诸如动态随机存取存储器或静态随机存取存储器（DRAM或SRAM）、可擦可编程只读存储器（EPROM）、电可擦可编程只读存储器（EEPROM）和闪存之类的半导体存储器设备，诸如硬盘、软盘和可换式盘之类的磁盘；包括磁带的其它磁性介质；诸如光盘（CD）或数字视频盘（DVD）之类的光学介质；或其它类型的存储设备。注意，上面论述的软件的指令能够提供在一个计算机可读存储媒介或机器可读存储媒介上，或者可替代地，可以提供在分布于可能具有多个节点的大型系统中的多个计算机可读存储介质或机器可读存储介质上。这种计算机可读存储媒介或介质或机器可读存储媒介或介质被认为是物品（或制品）的一部分。物品或制品能够指任意被制造的单个组件或多个组件。存储介质或存储媒介能够位于运行该机器可读指令的机器内或者位于能够通过网络下载用于运行的机器可读指令的远程位置。

在以上描述中，阐述大量细节，以提供对本文公开的主题的理解。然而，实现方式可以在没有这些细节中的一些细节或全部细节的条件下实践。其它实现方式可以包括上面介绍的细节的改变和变型。希望所附权利要求覆盖上述改变和变型。

Claims (15)

1.一种用于具有处理器的系统中的故障处理的方法，包括：

由第一子系统提供关于所述第一子系统的操作的状况指示；

由第二子系统检测所述第一子系统的故障；并且

响应于检测第一子系统的故障，

所述第二子系统更新状况指示来反映被检测的故障，以及

释放由已经经历所述故障的所述第一子系统使用的资源。

2.根据权利要求1所述的方法，其中所述第二子系统是监视子系统。

3.根据权利要求1所述的方法，其中释放资源由跟踪由所述系统中的子系统使用的资源的监视子系统执行。

4.根据权利要求3所述的方法，其中跟踪由子系统使用的资源包括跟踪从存储器、文件、硬件设备、软件模块、数据库连接和会话中选择的资源。

5.根据权利要求1所述的方法，进一步包括：

保持用于所述系统中各个子系统的资源的列表，该列表与子系统的各自的标识符关联；以及

检索与所述第一子系统的标识符关联的列表来识别由所述第一子系统使用的资源。

6.根据权利要求1所述的方法，其中所述状况指示包括对应的XML（可扩展标记语言）文件。

7.根据权利要求1所述的方法，进一步包括响应于由所述第二子系统更新的所述状况指示，执行补救行动。

8.根据权利要求7所述的方法，其中执行补救行动包括重启动所述第一子系统。

9.根据权利要求7所述的方法，其中执行补救行动包括引起所述第一子系统的失效来允许对所述第一子系统采取进一步的补救行动。

10.根据权利要求1所述的方法，其中所述系统具有处于层次化布置中的子系统，所述第二子系统位于该层次化布置的顶层，所述第一子系统位于该层次化布置的低层，并且其中所述系统进一步包括位于所述顶层和所述低层之间的中间层的子系统。

11.一种物品，包括存储用于系统中的故障处理的指令的至少一种机器可读存储介质，所述指令在运行时引起所述系统执行以下步骤：

接收关于第一子系统的操作的状况指示；

检测所述第一子系统的故障，其中所述状况指示不正确地指示所述第一系统正常操作，即便所述第一子系统已经经历故障；

响应于检测所述故障，更新由第二子系统提供的状况指示；以及

响应于检测所述故障，释放由所述第一子系统使用的资源。

12.根据权利要求11所述的物品，其中检测所述故障包括轮询所述第一子系统或对所述第一子系统使用心跳机制中之一。

13.根据权利要求11所述的物品，其中所述指令在运行时引起所述系统进一步：

响应于检测所述故障，更新所述第一子系统的状况指示。

14.根据权利要求11所述的物品，其中所述指令在运行时引起所述系统进一步：

跟踪由所述系统的子系统使用的资源；以及

提供被跟踪的资源的列表，其中该列表与子系统的对应标识符关联。

15.一种能够执行故障处理的系统，包括：

至少一个处理器，用于：

接收关于第一子系统的操作的状况指示；

检测所述第一子系统的故障，其中所述状况指示不正确地指示所述第一子系统正常操作，即便所述第一子系统已经经历所述故障；

响应于检测所述故障，更新由第二子系统提供的状况指示；以及

响应于检测所述故障，释放由所述第一子系统使用的资源。

Images