分析应用程序的适用性

创建数据服务的第一步是确定目标应用程序是否满足具有高可用性或可伸缩性的要求。如果应用程序没有满足所有要求，您可以修改应用程序源代码，使其具有高可用性或可伸缩性。

下表列出了要具有高可用性或可伸缩性的应用程序需要满足的要求。如果需要详细信息或者需要修改应用程序源代码，请参见附录 B，数据服务样例代码列表。

为了具有高可用性，可伸缩服务必须满足以下所有条件，同时还需满足下列项之后的一些附加条件。

• 在 Sun Cluster 环境中，网络可识别（客户机-服务器模型）和非网络可识别（无客户机）应用程序都有可能具有高可用性或可伸缩性。但是，在分时环境中，Sun Cluster 不能提供增强型可用性，在该环境下，应用程序在通过 telnet 或 rlogin 访问的服务器上运行。

• 该应用程序必须具有崩溃容限能力。也就是说，如果在节点发生意外毁坏的情况后启动应用程序，该应用程序必须能够在启动时恢复磁盘数据（如果有必要）。而且，崩溃后的恢复时间必须在限定范围内。崩溃容限是使应用程序具有高可用性的前提条件，因为恢复磁盘和重启应用程序的功能实质上是为了保持数据的完整性。不要求数据服务具有恢复连接的功能。

• 该应用程序不能依赖于运行时所在节点的物理主机名。有关附加信息，请参见主机名。

• 应用程序必须能够在多个 IP 地址被配置为“启用”的环境中正常运行。例如，节点位于多个公共网络中的多宿主 (multihomed) 主机环境，以及在一个硬件接口上多个逻辑接口被配置为“启用”的节点环境。

• 要具有高可用性，应用程序数据必须位于群集文件系统中。请参见多主机数据。

  如果应用程序针对数据位置使用硬连线路径名，您可以将该路径更改为指向群集文件系统中某一位置的符号链接，而无需更改应用程序源代码。有关附加信息，请参见将符号链接用于多主机数据放置。

• 应用程序二进制数据和库都可以位于各个本地节点或本地群集文件系统中。位于群集文件系统中的优点在于进行单个安装就可以了。缺点在于进行滚动升级时，应用程序在 RGM 的控制下运行的同时，也会使用二进制数据。

• 客户机应该具有在首次查询尝试超时后自动重试的功能。如果应用程序和协议已经处理了单个服务器崩溃和重新引导的问题，则可以处理有关资源组进行故障转移或切换的问题。有关附加信息，请参见客户机重试。

• 应用程序在群集文件系统中不能具有 UNIX® 域套接字或命名管道。

此外，可伸缩服务必须满足以下要求：

• 应用程序必须具有运行多个实例的能力，所有实例都在群集文件系统中相同的应用程序数据上进行操作。

• 应用程序必须保持数据一致性，以便从多个节点同时进行访问。

• 应用程序必须通过全局可视机制（例如群集文件系统）实现充分锁定。

对于可伸缩服务，应用程序的特征也可以确定负载平衡策略。例如，允许任一实例响应客户机请求的负载平衡策略 Lb_weighted 不能用于使用服务器内存中的高速缓存进行客户机连接的应用程序。在这种情况下，您应该指定一个负载平衡策略，以限制指定客户机到应用程序的一个实例的通信。负载平衡策略 Lb_sticky 和 Lb_sticky_wild 将反复地把客户机发出的所有请求发送到同一应用程序实例，在该实例中请求可以使用内存中的高速缓存。 请注意，如果传入的多个客户机请求来自不同的客户机，RGM 将在服务的实例中分配这些请求。有关设置可伸缩数据服务的负载平衡策略的更多信息，请参见实现故障切换资源。