分析應用程式的適當性

建立資料服務的第一步為確定目標應用程式滿足高度可用或可延伸的要求。 如果該應用程式不能滿足所有要求，您可以修改該應用程式的來源代碼以使其滿足所有要求。

以下清單概括了使應用程式高度可用或可延伸所應滿足的要求。 如果您需要更多詳細資訊，或您需要修改應用程式來源代碼，請參閱附錄 B, 範例資料服務程式碼清單。

可延伸服務必須滿足所有下列條件以及一些其他準則，才能高度可用。

• 支援網路 (主從式模型) 的應用程式和不支援網路 (無用戶端) 的應用程式均可在 Sun Cluster 環境中變得高度可用或可延伸。 但是，在共用時間環境中 Sun Cluster 無法提供增強的可用性，在該環境中應用程式執行於藉由 telnet 或 rlogin 存取的伺服器之上。

• 該應用程式必須為當機容限。 也就是說，它必須能在非預期的節點故障後，重新啟動時回復磁碟資料 (如有必要)。 而且，當機後的回復時間必須是有限的。 當機容限是應用程式高度可用所應必備的條件，因為回復磁碟並重新啟動該應用程式的能力關係到資料完整性問題。 不需要資料服務即可回復連接

• 應用程式不得依賴其執行所在節點的實體主機名稱。 請參閱主機名稱，以取得其他資訊。

• 應用程式必須在配置多個 IP 位址的環境中正常作業；例如具有多位址主機的環境 (在這種環境中節點位於多個公用網路上)，以及具有多個節點的環境，在這些節點上多個邏輯介面被配置為在一個硬體介面上。

• 若要高度可用，應用程式資料必須駐留在叢集檔案系統中 — 請參閱多重主機資料。

  如果應用程式使用該資料位置的固定連線路徑名稱，您可以將該路徑變更為指向叢集檔案系統中某個位置的符號連結，而無需變更應用程式來源代碼。 請參閱使用多重主機資料放置的符號連結，以取得其他資訊。

• 應用程式二進位檔和程式庫可駐留在本機的每個節點上或叢集檔案系統上。 駐留在叢集檔案系統上的優點是單一安裝即足夠。 其缺點是：由於應用程式在 RGM 控制下執行時二進位檔正處於使用中狀態，因此滾動更新就成了一個問題。

• 用戶端應該在首次嘗試逾時後能自動重試查詢。 如果應用程式和協定已處理了單一伺服器當機和重新啟動的情況，則它們也將處理故障轉移或切換保護移轉資源所在資源群組的情況。 請參閱用戶端重試，以取得其他資訊。

• 應用程式不得在叢集檔案系統中具有 Unix 網域套接字或具名管道。

此外，可延伸服務必須滿足下列要求。

• 應用程式必須能執行多個實例，且多個實例均運行在叢集檔案系統的同一應用程式資料上。

• 應用程式必須為多個節點的同時存取提供資料一致性。

• 應用程式必須透過全域可視機制 (如叢集檔案系統) 實施足夠的鎖護。

對於可延伸服務，應用程式特性還決定了負載平衡策略。 例如，負載平衡策略 LB_WEIGHTED (允許任意實例對用戶端請求做出回應) 不適用於為用戶端連接使用伺服器上記憶體內快取的應用程式。 在此情況下，您應該指定負載平衡策略，將指定用戶端的流量限定為應用程式的一個實例。 負載平衡策略 LB_STICKY 和 LB_STICKY_WILD 多次將某個用戶端的所有請求發送至同一應用程式實例 — 在此它們可使用記憶體內快取。 請注意，如果多個用戶端請求來自不同用戶端，則 RGM 在該服務的實例間分配這些請求。 請參閱實施故障轉移資源，以取得有關設定可延伸資料服務之負載平衡策略的詳細資訊。