集群选项的扩展

作者:Ken Dove

十年前,集群意味着一件事——将少量大型服务器与共享磁盘组合在一起,以托管在线事务处理应用程序,从而获得更高的可用性,在某些情况下,还可获得可扩展性。从那时起,我们看到了基于互联网的应用程序和精简的通用服务器的兴起,以及一个建立在 Linux 之上的全新的开放、可扩展、分布式计算模型。

Linux 领域的许多供应商正在努力重现十年前在传统 UNIX OLTP 系统上存在的那种集群。这可能不是正确的策略。相反,集群应该着眼于互联网数据中心和精简 Linux 服务器集群中部署的应用程序和架构类型。在互联网数据中心(无论是在托管环境还是在企业中),应用程序架构具有一些与旧式大型计算机架构根本不同的特征。特别是,互联网数据中心架构共享一些重要的共同主题

  • 架构是多层的(通常是 Web 服务器、应用服务器和数据库服务器)。

  • 每一层都可能真正拥有数十台服务器。

  • 每一层对于共享和复制的数据都有独特的需求。

在一个大型电子商务或 Web 内容站点中,管理通过 Web 提供服务的整个分布式资源集比仅仅为单个服务器提供故障转移更具挑战性。

虽然某些应用程序(如 OLTP 或某些类型的电子商务故障转移)仍然需要共享磁盘解决方案,但在许多情况下,现代应用程序可以利用中间件提供的基于软件的复制。他们缺乏的是将这些解决方案捆绑在一起并将其集成到更大的计算环境中的基础设施。应用程序管理(包括故障转移)仍然是当今运营经理面临的关键问题之一,但幸运的是,选择正在变得更好。

现在确实需要共享数据访问的应用程序通常涉及数十台机器,可能位于多个存在点 (POP) 中。这意味着即使是传统集群的共享磁盘解决方案(基于物理共享 SCSI 连接)也可能不足。这些解决方案受到物理布线和 SCSI 地址限制的约束,通常只能服务于两到四个系统。

Web 服务器层

Web 服务器层是 Linux 的堡垒,其特点是只读或动态创建的数据。这些数据可以并且经常通过使用运行 NFS 的网络附加存储设备在多台服务器之间共享。每台服务器都挂载 NFS 设备并有权访问正确的数据。对于这一层,复杂的共享 SCSI 布线方案完全不合适——TCP/IP 网络提供了服务器和存储之间的所有互连。然而,可以监控 Web 服务器的运行状况和性能,并根据来自这些监控器的输入采取适当操作的集群软件仍然非常重要。

应用层

在传统的企业大型计算机中,应用程序通常是客户端/服务器架构,并且基于关系数据库。在大多数情况下,数据不存储在应用程序层中——一切都放在数据库中。在 Internet/Linux 世界中,这种组合要丰富得多。Java 和 Enterprise JavaBeans 的出现导致开发人员将应用程序层对象序列化到文件系统中,数据库之外。此外,应用程序现在操作更丰富的数据宇宙——包括数字流媒体、文本和其他自然而然不存储在 SQL 后端的数据类型。

因此,应用层具有共享数据和故障转移要求,网络附加存储或共享 SCSI 都无法满足这些要求。网络附加存储通常不起作用,因为 NFS 协议没有提供足够的保证一致性,无法适用于多台服务器可能写入相同数据的情况。共享 SCSI 也不够用,因为复制或共享可能需要在许多系统或多个 POP 之间进行。因此,在许多情况下,应用程序提供自己的复制。例如,考虑一下数十家大型银行使用的外汇交易应用程序。实时交易数据的复制在应用层维护,并结合基于集群的故障转移。

数据库层

数据库层是大型 UNIX 供应商(Sun、HP 和 IBM)的传统集群解决方案的领域。最初,两台服务器将连接到一些 SCSI 磁盘,其中一台服务器是活动主服务器,另一台服务器是被动备用服务器。在更现代的实现中,多台服务器共享光纤通道或 SCSI 存储系统,并使用像 Oracle Parallel Server (OPS) 这样的并行数据库来管理集群中每个节点的并发访问。

然而,高端光纤通道 SAN 很昂贵,像 Oracle Parallel Server 这样的软件也很昂贵。通常,这些类型解决方案的性价比不适用于精简服务器 Linux 市场或互联网数据中心。主动/被动 SCSI 方法也浪费资源,并且可扩展性有限。幸运的是,还有其他更适合在 Linux 上运行的应用程序类型的方法。

例如,数据库供应商在共享无软件复制方法(Informix Replicator、DB/2 Replication、Oracle Multi-master 和热备)上投入了大量精力。使用这些工具,多台服务器可以在数据库层参与,而无需共享存储。然而,数据库本身通常缺乏检测故障、排序启动故障转移的操作以及保证应用程序完整性的功能。因此,它们最好与提供这些服务的集群解决方案配对。

一个真实的例子是一家芯片制造工厂,在基于 Intel 的精简服务器上运行制造自动化应用程序。由于此应用程序的价值,芯片制造商需要三向复制,这样即使主服务器发生故障,也有两台机器准备接管。选择的解决方案是使用 Informix 数据库复制服务在物理上分离的机器上运行,而无需共享存储,并结合集群管理引擎。

共享存储的未来

最后,某些应用程序确实需要物理共享磁盘。然而,由于共享 SCSI 仍然是一种不常见的配置,因此使用这种方法组装完整的系统需要小心——通常需要供应商进行完整的硬件/软件系统认证。(你上次检查磁盘固件级别是什么时候?)即使这一切都费力地组装在一起,正如我们所见,对于可以通过 SCSI 共享数据的节点数量以及可能的物理电缆布局都存在严重限制。光纤通道放宽了其中一些限制,但也有其自身的缺点,包括价格昂贵、多供应商互操作性问题以及许多 Linux 精简服务器用户不熟悉的一系列管理问题。

明年将看到共享存储面貌的巨大变化。行业领导者正在推动两项新的主要存储互连技术,这将使共享存储以适合精简服务器的价格点提供,并且还将支持互联网数据中心中看到的大量节点共享。Cisco 和 3ware 等热门初创公司正在支持基于 IP 的 SCSI,这将允许 SCSI 块协议在交换以太网结构上运行。英特尔和服务器供应商正在支持一种名为 Infiniband 的新 I/O 标准。它将提供一种交换 I/O 结构,最终可以在每个通用服务器主板上包含的芯片组中实现。事实上,这些发展是互补的——千兆以太网卡将能够位于 Infiniband 结构上并运行基于 IP 的 SCSI 协议。因此,我们可以期待在不久的将来,数十甚至数百个系统通过现代互连共享存储。集群解决方案为使用这些互连创建真正可管理和可扩展的分布式解决方案奠定了基础,这些解决方案将为未来的数据中心架构定下基调。

Ken Dove 是 PolyServe, Inc. 的首席架构师。此前,他曾担任 IBM 的杰出工程师,在此之前,他在 Sequent Computer Systems 担任首席软件架构师 12 年。

加载 Disqus 评论