存在一组标准,用于确定应用程序是否可以成为可伸缩服务。要确定应用程序是否可以成为可伸缩服务,请参见《Sun Cluster 数据服务开发者指南(适用于 Solaris OS)》中的“分析应用程序的适用性”。此组标准概述如下:
首先,此类服务由一个或多个服务器实例组成。每个实例运行在群集的不同节点上。同一服务的两个或更多实例不能在相同的节点上运行。
其次,如果服务提供外部逻辑数据存储,则您必须注意以下方面。从多个服务器实例对此存储的并发访问必须同步,以避免丢失更新信息或在数据更改时读取数据。请注意,此处所说的“外部”是与处于内存内状态的存储相区分。而所说的“逻辑”则表示存储作为一个实体出现(尽管它本身可能是复制的)。此外,此逻辑数据存储具有以下属性:不论何时只要有服务器实例更新了存储,其他实例就能立即“看到”该更新。
Sun Cluster 系统通过它的群集文件系统和全局原始分区来提供这样一个外部存储器。又比如,假设一项服务将新数据写入外部日志文件,或修改现有的数据。当此服务的多个实例运行时,每个服务都可以访问此外部日志,并且可能会同时访问这一日志。每个实例必须同步其对日志的访问,否则这些实例就会彼此干扰。此服务可以通过 fcntl(2) 和 lockf(3C) 来使用普通的 Solaris 文件锁定,从而实现所需的同步。
此类存储的另一个示例是后端数据库,如用于基于 SPARC 的群集的高可用性 Oracle Real Application Clusters Guard 或 Oracle。通过使用数据库查询或更新事务,此类型的后端数据库服务器可以提供内置同步功能。因此,多个服务器实例不需要实现各自的同步。
Sun 的 IMAP 服务器是非可伸缩服务的服务示例。该服务更新一个存储,但那个存储是专用的,并且当多个 IMAP 实例写入到这一存储时,它们因为更新没有被同步而相互覆盖。IMAP 服务器必须被重写以使并行访问同步。
最后,请注意实例可以拥有专用数据,这些数据与其他实例的数据毫不相干。在这种情况下,服务不需要同步的并发访问,因为数据是专用的,只有该实例才能对其进行处理。此时,您必须小心不要在群集文件系统下存储此专用数据,因为它可能会变为全局可访问的数据。