容错与网格

Arjuna Technologies是一家从HP独立出来的公司，他们的团队大部分都曾是世界上第一个Java事务服务和Web Service事务产品的幕后功臣，最近他们又把注意力转向了如何把他们的专业经验应用到网格的世界。他们最近的一份白皮书中说：

为了获得灵活性与更高的资源利用率而做出的妥协与权衡导致了IT基础设施的复杂性上升。[……]然而，结果是数据的共享更加普遍，而其效应也更难预测。用户更难清晰地理解一个动态演进中的IT设施的行为。这会导致几个问题，特别是当数据资源最初的设计是在一个条块分割的环境中使用，或者当设施设计之初忽视了共享访问的微妙难解之处。

正如文中指出的，迈向SOA与更高的灵活性的过程中需要做出妥协：天下没有免费的午餐。虽然数据共享程度提高了，但对整体控制以及环境中的执行情况缺乏了解，使得我们很难去理解数据共享的程度和本质。这就导致可靠性和容错性的方面变得复杂起来。这份白皮书接着讨论了数据共享的提升（特别是在企业网格中）是如何给基础设施提供商带来麻烦的，他们现在要考虑如何在存在失败与并发访问的前提下保证数据的一致性与连贯性。他们更进一步指出，虽然数据的复制、缓存与分区有助于提升性能和可用性，但：

……解决性能问题会引入新的麻烦。必须引入同步过程（Synchronisation）来确保视图的连贯性与一致性，而这需要一个协议来满足在分布的多方间通讯的需求。

Arjuna认为目前流行的网格方案都假设很少或不存在数据共享，这样可以相对简化容错。否则基础设施必须保证防止不一致的状态玷污整个应用。

……具备适当支持的系统要么可以“回滚”到前一个一致的状态（向后恢复），或者通过“补偿”来获得一个新的一致状态。没有这些，企业所依赖的数据就面临着真实的数据受损的危险。

这些都是我们在JEE、CORBA、.NET或者Web Services当中习以为常的东西，因此这里并不存在什么根本上的问题。然而，我们讨论的要点是，在现有的许多数据网格方案中，仅有的容错手段就是重新启动应用，这对于共享数据的应用来说是不充分的。不充分是因为它们只关注数据的连贯性，而没有为数据的一致性提供作用域机制。如果在JEE里使用事务而不进行任何并发控制，结果也是一样。

最近已经出现了很多向网格加入容错的工作，其中一些也跟上述白皮书一样得出基础设施需要升级的结论：

• 识别数据共享，并保护应用免受波及：错误防止
• 监控数据共享：错误检测
• 记录数据改变以助恢复：错误恢复
  

我们还留下了几个疑问：当前数据网格设施的用户感受到了缺乏这些组件的痛苦吗？如果没有，为什么没有，既然对于其他分布式系统来说，这些都是必不可少的功能？在网格中数据共享是很少出现的场景吗？也许补偿式事务由应用来处理比交给基础设施来处理更好？

查看英文原文： Fault Tolerance and the Grid