高可用性
幾乎每個 PTC 客戶都相當關注可用性。系統的可用性程度以及嚴重損壞復原時間對於架構組態有重大影響。嚴重損壞所需的平均復原時間 (MTTR) 是決定架構所需功能的重要因素。可用性和所需平均復原時間兩者關係密切，對於包括 Servigistics InService 在內的任何系統的組態和成本都有極大的影響。
請記住，針對可用性的定義或要求可能會因人而異。例如，請考慮下列問題：
如果執行應用程式的伺服器正常運作，但是網路發生故障，系統是否仍可用？
對於系統管理員以及不受影響之網站的管理員，系統仍可用。對於某個網站的最終使用者，系統明顯不可用。您需要回答的問題如下：
基礎結構中的所有元件需要達到多大的備援程度，才能稱為達到高可用性？
有多種高可用性組態 - 反映出客戶的不同需求。在一些最簡單的情況下，客戶會利用其硬體基礎結構的多個元件，來在剩餘可用硬體中重新配置其環境。HP、Sun、IBM 和 VMware 等硬體廠商提供的分割區行動解決方案可以在實體伺服器之間變換應用程式。現在，傳統意義上的主動/被動行為可以使用這些解決方案的主動/主動能力完成。其他客戶則在不同位置的資料中心中維護重複的生產環境，用來接收生產的同步處理最新。在前述兩種極端情況之間有許多種可能的組態，可配合各種客戶需要或預算。
平均復原時間 (MTTR) 是管理員可從嚴重損壞中復原系統所需的速度。某些客戶明確區分硬體問題造成的故障與天災造成的問題所需的 MTTR。大型系統可從備份進行還原所需的速度會直接影響基礎結構的成本。這些速度通常取決於現有基礎結構支援資料復原的實際限制。
在資料復原時間不超過 8 小時的情況下，時間對基礎結構成本和複雜度的影響將以一或多個數量級增加。在嚴重損壞造成大規模故障的情況下，解決大規模系統中斷的可接受復原時間一般較長，因為其他重要系統的優先順序可能高於 Servigistics InService 解決方案。
決定高可用性需求與部署需求時，對於大規模實行，應該將 Servigistics InService Publisher 與 Servigistics InService Viewer 視為兩個單獨的應用程式。
針對 Servigistics InService Publisher：
• 高可用性需求包括對於發佈最新版服務內容和提供其存取權套用的優先順序。反複內容的發佈能夠等候一天或兩天嗎？可以多快產生 Publisher 備份應用程式？此類問題的答案有助於決定是否需要 Publisher 的高可用性，或其他 (較慢) 重新部署程序是否足夠。
• 無法將 Servigistics InService Publisher 應用程式配置為叢集應用程式。Publisher 的高可用性部署將使用主動/被動解決方案。被動伺服器需要至少在每個發行任務後更新。
• 對於支援 Publisher 應用程式的 WindchillDS 安裝，應該使用 DS 複製來使主動與被動 WindchillDS 安裝保持同步。
• 應該在主動或被動 Publisher 可存取的通用磁碟上維持 E3C Storage 目錄和 Work 目錄。
• 應該在可支援 Servigistics InService Publisher 高可用性需求的高可用性解決方案上維持 Oracle 資料庫。
對於 Servigistics InService Viewer：
• 一般認為，Servigistics InService Viewer 應用程式的可用性需求高於 Publisher 應用程式。Viewer 的高可用性需求包括維持使用者對已發佈服務內容之存取權時所套用的優先順序。此系統對於您的業務需求有多重要？最高可接受多大程度的效能延遲？已發佈內容對於使用者不可用的時間多長？此類問題的答案有助於決定高可用性部署。
• 高可用性的第一步是配置 Servigistics InService Viewer，使其作為單一發佈網站內的叢集來執行作業。叢集一開始用於支援大量使用者，但也能為系統提供高可用性。現在，透過將一個額外的伺服器新增至 Viewer 叢集，可以應對一個 Viewer 應用程式離線的情況，由於額外的 Viewer 伺服器能夠因應離線伺服器的損失，因此使用者效能不會受到影響。
• 獲得高可用性的下一步是配置 Viewer 應用程式在兩個或兩個以上的資料中心運作。這稱為多網站發行組態。在每個資料中心建立至少一個 Viewer。也可以在每個資料中心建立一個 Viewer 叢集。如果一個資料中心離線，則正常運作的資料中心中的 Viewer 可以管理使用者流量。
• 可以配置 Servigistics InService Viewer 來辨識多個主動/被動形式的 WindchillDS 安裝。高可用性組態應該至少有兩個 WindchillDS 安裝。單一網站組態則應該有兩個 WiIndchillDS 安裝。對於多網站安裝，每個網站應該至少有一個 WindchillDS 安裝。
• 必須在每個網站中維護 E3C Storage 位置。網站內的所有 Viewer 都應該能夠存取該網站中受維護的 E3C Storage 位置。
• 單一網站系統的 Oracle 高可用性需求應支援 Servigistics InService Viewer 應用程式的需求 (多網站系統的 Oracle 高可用性需求較為詳細)。
• 每個網站應使用四種結構描述 (E3C、Titan、Titan2、CMI)。(例如，對於兩個網站的解決方案，每類結構描述都應該有兩個 (一個網站一個)，且最好與支援的 Viewer 位於同一個資料中心中)。
• 對於 Windchill 結構描述，整個系統應該只有一個此類結構描述，並由所有網站的所有 Viewer 共用。此結構描述可能需要跨越多個資料中心的 Oracle 高可用性解決方案，例如 dataguard 或 Real Application Clusters (RAC)。