SharePoint Server 設計範例:公司入口網站及外部網站

 

**適用版本:**SharePoint Foundation 2013, SharePoint Server 2013, SharePoint Server 2016

**上次修改主題的時間:**2017-08-21

**摘要:**說明最常用之 SharePoint 2013 和 SharePoint Server 2016 設計範例的邏輯架構設計選擇。

本文討論可作為 SharePoint 網站起始點架構的幾種設計範例。本文所述的設計範例說明公司或組織內最常部署之 SharePoint 網站類型的標準架構。

本文內容:

  • 關於設計範例

  • 設計範例所包含的網站

  • 整體設計目標

  • 伺服器陣列

  • 使用者、區域及驗證

  • 服務

  • 管理網站

  • 應用程式集區

  • Web 應用程式

  • 網站集合

  • 內容資料庫

  • 區域及 URL

  • 區域原則

重要

本文資訊適用於 SharePoint Foundation 2013 和 SharePoint Server。但是,本文討論 SharePoint Foundation 2013 不提供的特定功能,例如「我的網站」及企業搜尋。

關於設計範例

本文說明下列設計範例:

這些設計範例以虛構公司 Fabrikam, Inc. 的網站進行。這些設計範例幾乎適用於所有邏輯架構元件,並這些元件如何應用在整體設計中。本文範例設計目標,並解釋範例所示的邏輯架構元件如何達成這些目標。

注意

模型在標題中有 SharePoint 2013,但仍適用於 SharePoint Server 2016

公司入口網站設計範例 - 兩種版本

SharePoint Server 的主機命名型網站集合在單一 Web 應用程式內,提供網站的 URL 管理及延展性。這兩種公司入口網站設計範例版本顯示以傳統路徑型網站集合或主機命名型網站集合為使用基礎的實作。這兩種設計範例均搭配單一區域使用宣告式驗證。本文稍後將更詳細討論這些範例。

除非有需求指出必須要有搭配了備用存取對應的路徑型網站 (如需詳細資訊,請參閱<SharePoint Server 中已指定主機的網站集合架構與部署>),否則建議使用以主機命名型網站集合為基礎的設計。建議採用此種設計的原因是因為它的架構與 Office 365 環境所使用的架構相同。因此,這是受到最嚴厲測試的組態。新功能 (包括應用程式模型和要求管理) 已針對此組態最佳化,因此此組態是從今以後的版本最可靠的組態。

設有驗證專用區域的外部網路

「具有驗證專用區域的外部網路」設計範例僅包含合作夥伴網站。此設計範例提供合作夥伴共同作業的其他設定,在此設定中,每個驗證方法各有專用區域。每個設計範例針對 Web 應用程式使用宣告模式驗證。公司入口網站設計範例與外部網路設計範例之間的差異在於區域的設定方式。「具有驗證專用區域的外部網路」設計範例使用多個區域,且每個區域設定一種驗證方法。公司入口網站設計範例使用一個區域,並針對不同類別的使用者設定多種驗證方法。

「具有驗證專用區域的外部網路」設計範例也引進新的遠端員工存取建議 (透過 Windows Server 2012 直接存取)。此建議的另外一種作法是建立虛擬私人網路 (VPN)。您也可以視需要在防火牆或閘道產品上使用表單型驗證,以收集及轉送認證。

設計範例中實作網站集合的方式

雖然舊版的公司入口網站設計範例使用路徑型網站集合,但是建議從今以後的版本都使用主機命名型網站集合,除非有需求指出必須使用搭配了備用存取對應 (AAM) 的傳統路徑型網站。這會在設計範例中以下列方式反映:

  • 採用路徑型網站集合的公司入口網站 - 此範例傳統路徑型網站集合,網站會組織在專用的 Web 應用程式中,且每個 Web 應用程式各有一個頂層網站集合。如果您想透過使用個別應用程式集區的多個 Web 應用程式提供額外的安全性,請使用此方法。

  • 採用主機命名型網站集合的公司入口網站 - 此範例使用主機命名型網站集合,將所有網站部署在伺服器陣列上的單一 Web 應用程式中。此方法的延展性極高,並可更彈性地管理 URL。

  • 設有驗證專用區域的外部網路 - 此範例使用虛名 URL 的許多頂層專案網站,其方式是使用主機名稱網站代表每個專案網站 (而不是在頂層網站集合之下組織專案網站)。以此方式使用主機命名型網站集合的一項優點,是建立網域 URL 之間的額外隔離,合作夥伴共同作業解決方案可能需要此額外的隔離。但是,此方法的缺點是由於管理更多主機名稱 (包括管理 SSL 憑證),而導致成本增加。此外,如果使用 SAML 驗證,也需要其他設定 (請參閱本文稍後的<搭配主機名稱網站使用 SAML 驗證>)。

SharePoint Server 的宣告式驗證

SharePoint Server 中的驗證運作方式,會影響與實作這些設計範例所代表之選項相關的設計決策。以下為一些範例:

  • 在 SharePoint Server 中,宣告式驗證是預設模式,也是唯一透過管理中心提供的選項。傳統模式驗證可透過 PowerShell 實作。

  • 在 SharePoint Server 中,您不需要在負載平衡器上設定伺服器相關性,以使用 SAML 宣告驗證。SharePoint Server 完全支援非相關性負載平衡。

在 SharePoint Server 中,搜尋編目帳戶必須使用整合式 Windows 驗證 (NTLM 或 Kerberos) 透過「預設」區域存取內容。由於宣告驗證允許一個區域有多種驗證類型,因此這項需求應該不會影響其他驗證需求。

設計範例功能摘要

下表摘要本文所討論的三種設計範例。

表:設計範例摘要

設計範例 包含 主要設計元素

採用路徑型網站的公司入口網站

組織內最常部署的網站類型。

  • 路徑型網站集合

  • 宣告式驗證

  • 單一區域實作多個驗證提供者及驗證類型

採用主機名稱網站的公司入口網站

組織內最常部署的網站類型。

  • 主機命名型網站集合

  • 宣告式驗證

  • 單一區域實作多個驗證提供者及驗證類型

設有驗證專用區域的外部網路

僅限合作夥伴網站。提供合作夥伴共同作業的其他設定。

  • 主機命名型網站集合

  • 宣告式驗證

  • 每個驗證方法使用不同區域

設計範例所包含的網站

本節設計範例中包含的頂層網站。

內部網路網站

公司入口網路包含下列用於內部網路的網站:

  • 已發佈的內部網路內容 (例如 HRweb)

  • 共同作業小組網站

  • 我的網站

這些都是員工每天使用的內容和共同作業網站。這些應用程式各自代表特殊的內容類型。每種內容類型包含下列屬性:

  • 強調 SharePoint Server 的不同功能。

  • 主控不同資料特性的資料。

  • 會因不同使用設定檔而異。

  • 需要不同的權限管理策略。

因此,上述每個應用程式的設計選擇都是要最佳化每個應用程式的效能及安全性。

服務應用程式的設計將結合上述三個應用程式,以提供下列功能:

  • 整體企業搜尋

  • 共用設定檔資料及企業中繼資料

下圖擷取自「採用路徑型網站集合的公司入口網站」設計範例,顯示組成公司內部網路的三種網站類型。

組成公司內部網路的網站類型

內部網路網站

合作夥伴 Web 應用程式

合作夥伴 Web 應用程式會架設可供外部使用的網站,以與合作夥伴公司和個別合作夥伴進行安全的共同作業。此應用程式的目的是要讓員工輕鬆地建立網站以進行安全的共同作業。合作夥伴將無權存取伺服器陣列主控的其他內容類型。區域和服務應用程式均針對此目的而設計。此外,個別網站擁有人可管理其網站的權限,並僅邀請必要的參與者共同作業。

在外部網路設計範例中,這是唯一的代表性網站類型。

整體設計目標

設計範例提供 SharePoint Server 功能在數種常見網站類型中的實際實作。本文將討論每種個別應用程式的設計實作。設計範例的主要設計目標如下:

  • 在設計環境時,建立一個可以成長的架構。

    個別網站類型的設計決策將不會妨礙新增其他網站類型。例如,初始部署可能只包括共同作業小組網站,或只包括構成內部網路的三個網站類型 (小組網站、「我的網站」及已發佈的內部網路內容)。如果使用類似的邏輯架構設計,則可以將網站新增至解決方案,而不會影響初始解決方案的設計。換言之,此設計不包含限制環境使用的設計選擇。

  • 在不影響不同網站類型的內容安全性之下,為多個使用者群組提供存取權。

    來自不同網路區域 (內部網路及外部網路) 且使用不同驗證提供者的使用者都可以參與共同作業。此外,使用者只能存取他們可以存取的內容。如果依照類似的邏輯架構設計,則可對位於多個位置以及具有不同目標的使用者提供存取權。例如,您的初始設計可能只是要讓內部員工存取。不過,如果使用類似設計,您也可以讓遠端員工、合作夥伴員工、合作夥伴公司及客戶進行存取。

  • 確定設計可用於外部網路環境。

    謹慎地做出設計選擇,以確保解決方案能夠安全地部署於周邊網路。

本文其餘部分將討論出現在設計範例中的每個邏輯元件 (從上到下),並討論應用於設計範例的設計選擇。此方法的目的在於示範根據應用程式設定邏輯架構元件的不同方式。

伺服器陣列

本節設計範例所述的伺服器陣列拓撲,並討論如何擴充超過一個伺服器陣列。

伺服器陣列的拓撲

設計範例中的每個伺服器陣列都是由具有下列容錯拓撲的六部伺服器所組成:

  • 兩部前端網頁伺服器

  • 兩部應用程式伺服器

  • 兩部安裝 SQL Server 並設定為支援 SQL Server 叢集、鏡像或 AlwaysOn 的資料庫伺服器。AlwaysOn 需要 SQL Server 2012。

前端和應用程式伺服器的概念不同於 SharePoint Server 2016 的概念,請參閱<SharePoint Server 2016 的 MinRole 伺服器角色概觀

此設計範例 SharePoint Server 的邏輯架構,如下所示:

  • 在前端網頁伺服器間鏡像所有網站。

  • 管理中心網站安裝在應用程式伺服器上,讓使用者無法直接存取。

實際上,伺服器電腦數目及伺服器陣列拓撲只在增加容量和提升效能時,對邏輯架構而言才重要。您可以設計與伺服器陣列拓撲無關的邏輯架構。效能及容量規劃程序可協助您規劃伺服器陣列的大小,以符合效能及容量目標。如需詳細資訊,請參閱<規劃 SharePoint Server 2013 中規劃效能>。

使用者、區域及驗證

宣告是 SharePoint Server 的預設驗證模式,因此每個設計範例都會採用宣告式驗證。您可以使用 Windows PowerShell 實作傳統模式驗證,但是在傳統模式中無法使用某些 SharePoint Server 功能。如需採用傳統模式驗證之設計範例的詳細資訊,請參閱<設計範例:公司部署 (SharePoint Server 2010)

下表列出公司入口網站設計範例與外部網路設計範例分別代表的兩個方法之間的差異。

表:比較設計範例中區域設定的方法

採用主機名稱網站的公司入口網站及採用路徑型網站的公司入口網站 設有驗證專用區域的外部網路

驗證模式

宣告

宣告

區域設定

一個區域,其中包含針對不同類別之使用者設定的多種驗證方法。

多個區域,其中每個區域設定一種驗證方法。

URL

所有類別的使用者使用相同的 URL 來存取所有網站。不論員工在公司網路內部或在遠端工作,都會使用相同的 URL。

各類別的使用者使用不同的 URL 來存取網站。員工根據在公司網路內部或在遠端工作使用不同的 URL。

內部要求

在公司網路內部起始的要求會透過閘道或 Proxy 伺服器傳出再傳回網路。這些要求使用 Secure Sockets Layer (SSL) 通訊協定保護。

您也可以使用分割 DNS 將要求直接路由傳送至伺服器的內部介面。

在公司網路內部起始的要求會保留在公司內部。

使用者經驗

系統會提示所有使用者選擇其用來登入的帳戶類型。

驗證方法已預定。使用者不需要透過登入頁面選取帳戶類型。

下列各節將特別討論如何透過這兩種不同方法使用驗證。

設有專用區域的外部網路設計範例

外部網路設計範例三種類別的使用者,每種類別使用者各指派至不同區域。在每個 Web 應用程式內,使用其中一種可用的區域名稱 (預設、內部網路、網際網路、自訂或外部網路),最多可建立五個區域。如設計範例所述,搜尋編目帳戶必須使用整合式 Windows 驗證 (NTLM 或 Kerberos 通訊協定) 存取「預設」區域。下表顯示外部網路設計範例中的區域設定方式。

表:外部網路設計範例所規定的區域、使用者及驗證類型

區域 使用者 驗證

內部網路

內部及遠端員工

搜尋編目帳戶

NTLM 或 Kerberos 通訊協定

使用直接存取或 VPN 連線的遠端員工。

預設

不同的合作夥伴

選項:

  • 使用表單型驗證的 LDAP 目錄

  • 與內部樹系具有單向信任並使用整合式 Windows 驗證的對外 Active Directory 網域服務 (AD DS) 樹系

  • 使用 SAML 驗證之信任的身分識別提供者

外部網路

合作夥伴公司

使用 SAML 驗證之信任的合作夥伴身分識別提供者

公司入口網站設計範例

宣告式驗證允許同一個區域使用多種驗證類型。公司入口網站設計範例的兩種版本針對所有驗證類型使用「預設」區域。

下表顯示設計範例所規定的區域、使用者及驗證類型。

表:公司入口網站設計範例的區域、使用者及驗證

區域 使用者 提供者及驗證類型

預設

內部及遠端員工

使用表單型驗證或 SAML 驗證的 Active Directory 網域服務 (AD DS) 或 LDAP 存放區。

預設

不同的合作夥伴

使用 SAML 驗證之信任的身分識別提供者,或使用表單型驗證的 SQL Server 資料庫

預設

合作夥伴公司

使用 SAML 驗證之信任的合作夥伴身分識別提供者

預設

搜尋編目帳戶

使用 Windows NTLM 驗證的 AD DS

在設計範例中,「已發佈的內部網路內容」網站、「小組網站」及「我的網站」僅可供員工 (包括位於內部及外部網路的員工) 存取。本設計範例針對這些可在內部及外部使用的網站,僅實作一個 URL (使用的是 SSL),且使用 AD DS 帳戶。如果需要,表單型驗證或 SAML 可以使用 LDAP,不過這需要額外設定。

在本設計範例中,合作夥伴 Web 應用程式代表的是可讓合作夥伴員工及合作夥伴公司存取的外部網路網站。在此情況下使用的宣告式驗證需要設定與一或多個外部身分識別提供者的信任。您可以使用下列其中一種方式:

  • 您可以設定 SharePoint 伺服器陣列信任外部身分識別提供者,例如位於合作夥伴公司的提供者 (以直接驗證合作夥伴目錄)。

  • 您可以設定公司環境中的身分識別提供者信任外部身分識別提供者。這兩個組織中的管理員必須明確建立此關係。在此情況下,SharePoint 伺服器陣列會信任位於其自己公司環境內的身分識別提供者。當身分識別提供者傳送 Token 時,伺服器陣列會使用建立信任時所指定的 Token 簽署憑證,來確認 Token 是否有效。建議使用此方法。

另一種替代宣告式環境驗證合作夥伴的方式是表單型驗證。您可以使用個別存放區 (例如資料庫) 來管理這些帳戶。

區域

當您設計區域時,有多個對部署成功與否十分重要的重要決策。這些決策包括下列區域的設計和設定決策:

  • 預設區域

  • 進行外部存取的區域

下列各節說明設計範例中所採用的決策。

預設區域的設定需求

最需要仔細考量的區域就是「預設」區域。SharePoint Server 對於「預設」區域的設定方式有下列需求:

  • 當使用者要求無法與區域建立關聯時,會套用「預設」區域的驗證和原則。因此,「預設」區域必須是最安全的區域。

  • 管理電子郵件訊息包含「預設」區域的連結。這包括送給將達到配額限制之網站擁有人的訊息。因此,收到這類訊息和提醒的使用者,必須可透過「預設」區域存取連結。這對網站擁有人特別重要。

在 SharePoint Server 中,已指定主機的網站集合可以從任何區域存取。

為外部網路環境設定區域

在外部網路環境中,區域的設計十分重要,原因在於下列兩個因素:

  • 有多個不同的網路可以起始使用者要求。在設計範例中,使用者會從內部網路、網際網路及合作夥伴公司起始要求。

  • 使用者會使用多個 Web 應用程式的內容。在設計範例中,內部網路由三個 Web 應用程式組成。此外,內部及遠端員工可能會在合作夥伴 Web 應用程式中提供和管理內容。

如果外部網路環境包含多個區域,請務必遵循下列設計原則:

  • 跨多個 Web 應用程式設定區域彼此鏡像。驗證設定和預定使用者應該相同。但各 Web 應用程式中與區域相關的原則可互不相同。例如,您必須確定相同的員工在所有 Web 應用程式中皆是使用內部網路區域。換言之,請勿在某 Web 應用程式設定內部網路區域供內部員工使用,而在另一個 Web 應用程式中將該區域設定供遠端員工使用。

  • 如果使用路徑型網站集合,請針對每個區域和每個資源,適當且正確地設定備用存取對應。備用存取對應會在您建立區域時自動建立。但是,您可以設定 SharePoint Server 對外部資源 (例如檔案共用) 中的內容進行編目。您必須使用備用存取對應為每個區域手動建立連至這些外部資源的連結。

  • 如果使用主機命名型網站集合,請確定使用 PowerShell 將 URL 對應至適當的區域

如果跨 Web 應用程式中的區域未彼此鏡像,且外部資源連結不正確,則會發生下列風險:

  • 伺服器名稱、網域名稱系統 (DNS) 名稱及 IP 位址可能會公開於內部網路之外。

  • 使用者可能無法存取網站和其他資源。

搭配主機名稱網站使用 SAML 驗證

如果設計需要搭配主機名稱網站使用 SAML 驗證,每個虛名 URL 需要下列項目:

  • SPTrustedIdentityTokenIssuer 上的新領域

  • 身分識別提供者中的對應信賴憑證者。

服務

服務架構會隨設計範例而有所不同。「採用主機名稱網站的公司入口網站」設計範例包含最簡單的服務架構。這是因為此設計範例使用一個 Web 應用程式,該 Web 應用程式只能容納一個服務應用程式群組 (又稱為 Proxy 群組)。

「採用路徑型網站的公司入口網站」範例使用合作夥伴網站的已分割服務,以隔離不同專案的資料。此設計範例包含兩個服務群組,其中一個用於內部網路網站,另一個用於合作夥伴共同作業網站。合作夥伴網站上會部署不同之受管理的中繼資料執行個體及搜尋執行個體,並分割這些服務。分割的服務需要訂閱設定服務,該服務只能透過 PowerShell 部署。

採用路徑型網站的公司入口網站服務架構

服務架構

部署分割的服務會增加架構的複雜性,且稍後會更難將網站移轉至 Office 365。如果 Managed Metadata Service 執行個體和 Search Service 執行個體必須不同,對於合作夥伴網站而言較簡單作法是部署專用但未分割的執行個體。許多組織會依賴搜尋的安全性調整功能,而不是部署 Search Service 的專用執行個體。

外部網路設計範例只包含一個 Proxy 群組,但是此設計範例也使用 Managed Metadata Service 和 Search Service 應用程式的分割服務。

部署服務應用程式的主要設計決策,在於如何廣泛使用組織分類。若要簡化服務架構,可在所有 Web 應用程式之間共用受管理的中繼資料、使用者設定檔及搜尋,再藉由安全性調整來管理內容存取權。在「採用路徑型網站的公司入口網站」設計範例中,所有網站共用一個 Managed Metadata Service 執行個體。不過,在此設定下,所有使用者都能存取公司分類。解決方案架構師必須決定是否要實作多個 Managed Metadata Service 執行個體,也需決定如何廣泛共用使用者設定檔資料。

在「採用路徑型網站集合的公司入口網站」範例中,合作夥伴網站會設定為透過自訂服務群組使用專用 Search Service 和 Managed Metadata Service 應用程式。其他服務應用程式會加入自訂群組,並透過此預設群組共用。此設計範例不包含 User Profile Service 應用程式,因此可防止合作夥伴使用者瀏覽組織中的人員資料。

在「採用主機命名型網站集合的公司入口網站」的簡化架構 (一個服務群組) 中,合作夥伴可存取整個公司分類,也可瀏覽組織中的人員資料。但是,搜尋結果範圍限為合作夥伴可存取的網站及內容。

如果您的合作夥伴網站需要將專案之間的內容加以隔離,部署專用的服務應用程式 (如本文所示) 會是不錯的選擇。此作法雖然會使服務架構變得較複雜,但可以確保合作夥伴無法存取與內部網路內容相關的中繼資料,或甚至是合作夥伴網站內其他專案。外部網路設計範例也使用分割的服務。

管理網站

在設計範例中,會由應用程式伺服器主控每個伺服器陣列的 SharePoint 管理中心網站。如此可避免使用者直接連接到網站。如果效能瓶頸或安全性危害影響到前端網頁伺服器的可用性,則 SharePoint 管理中心網站會保持在可用狀態。

本設計範例及本文不涵蓋管理網站的負載平衡 URL。建議如下:

  • 如果管理 URL 使用連接埠號碼,請使用非標準連接埠。URL 預設會包括連接埠號碼。雖然客戶對應 URL 通常不會包括連接埠號碼,不過管理網站使用連接埠號碼將可提高安全性,因為可將對這些網站的存取限制在非標準連接埠上。

  • 為管理網站建立單獨 DNS 項目。

除了這些建議之外,您還可以讓 SharePoint 管理中心網站在多部應用程式伺服器之間達到負載平衡,以達到備援目的。

應用程式集區

實作單獨 Internet Information Services (IIS) 應用程式集區的目的,一般是為了隔離內容之間的處理序。應用程式集區可讓多個網站在相同的伺服器電腦上執行,且仍然保有其各自工作者處理序及身分識別。這可防止攻擊者透過在其中一個網站插入程式碼,來影響其他網站上的其他伺服器或網站。

如果將單一應用程式集區和 Web 應用程式搭配主機命名型網站集合使用,則只會在指令碼層級提供網域 URL 之間的隔離。

如果選擇實作多個應用程式集區,請考慮針對下列各個案例使用專用應用程式集區:

  • 要區隔已驗證內容與匿名內容。如果由同一個伺服器陣列架設公司網際網路網站,請將此網站置於專用 Web 應用程式和應用程式集區中。

  • 要將儲存後端資料系統密碼的網站,與會和後端資料系統互動的網站之間有所隔離 (雖然可改用 Secure Store Service 來達到這個目的)。

「採用主機名稱網站的公司入口網站」設計範例及「設有驗證專用區域的外部網路」設計範例會實作單一應用程式集區及 Web 應用程式來存放所有內容。服務應用程式和 SharePoint 管理中心網站需要不同的應用程式集區。

「採用路徑型網站的公司入口網站」設計範例使用下列方式,透過個別應用程式集區來實作內容之間的處理序隔離:

  • 管理網站都架設在專用應用程式集區中。這是 SharePoint Server 的需求。

  • 所有服務應用程式會部署至單一應用程式集區。除非有其他有力的原因,必須將服務應用程式部署至不同應用程式集區,否則這會是建議的設定。針對所有服務應用程式使用一個應用程式集區可最佳化效能,並減少要管理的應用程式集區數目。

  • 內部網路內容分成兩個不同應用程式集區。其中一個應用程式集區主控共同作業內容 (「我的網站」及小組網站);另一個應用程式集區主控已發佈的內部網路內容。此設定可為較可能使用商務資料連線的已發佈內部網路內容提供處理序隔離。

  • 專用應用程式集區主控合作夥伴 Web 應用程式。

Web 應用程式

Web 應用程式係為 SharePoint Server 所建立並使用的 IIS 網站。每個 Web 應用程式在 IIS 中代表不同網站。

如果選擇實作多個 Web 應用程式,請考慮下列使用案例:

  • 使匿名內容與已驗證內容之間有所區隔

    如果由同一個伺服器陣列架設公司網際網路網站,請將此網站置於專用 Web 應用程式和應用程式集區中。

  • 隔離使用者

    在設計範例中,會由專用 Web 應用程式及應用程式集區架設合作夥伴網站,確保合作夥伴無法存取內部網路內容。

  • 強制規定權限

    專用 Web 應用程式可對 Web 應用程式內的區域實作原則以強制執行權限。例如,您可以為公司網際網路網站建立原則,明確拒絕一或多個使用者群組的寫入權限。不論 Web 應用程式中個別網站或文件上設定的權限為何,都會強制執行原則。

  • 最佳化效能

    若 Web 應用程式與其他具有類似資料特性的應用程式放在一起,則這些應用程式可達到較好的效能。例如,「我的網站」的資料特性包括大量規模較小的網站。相對地,小組網站通常會包含少量的極大型網站。將這兩種不同類型的網站置於不同的 Web 應用程式,產生的資料庫就會包含特性類似的資料,如此可最佳化資料庫效能。在設計範例中,「我的網站」及小組網站並沒有特有的資料隔離需求,它們會共用相同的應用程式集區。不過,「我的網站」及小組網站會置於不同的 Web 應用程式中,以最佳化效能。

  • 最佳化管理性

    建立不同 Web 應用程式會產生不同的網站和資料庫,所以您可以實作不同的網站限制 (資源回收筒、到期時間和大小),以及交涉不同的服務等級協定。例如,如果「我的網站」內容不是您組織中最重要的內容類型,您可能會允許較多時間來還原這些內容。如此可讓您先還原較重要的內容,再還原「我的網站」內容。在設計範例中,「我的網站」位於不同的 Web 應用程式中,可讓管理員能夠較對待其他應用程式採取更積極的方式,管理「我的網站」的成長。

如果搭配單一 Web 應用程式實作主機命名型網站集合,每個頂層網站會是個別網域,以讓您達成其中一些目標,例如透過實作不同的網站限制來最佳化管理性。

網站集合

部署網站時,建議組態為使用主機命名型網站集合,其中所有網站皆位於單一 Web 應用程式內。建議使用此設定來部署網站,因為其與 Office 365 環境使用的架構相同。因此,這是受到最嚴厲測試的組態。新功能 (包括應用程式模型和要求管理) 已針對此組態最佳化,因此此組態是從今以後的版本最可靠的組態。

儘管建議您對大多數的架構使用主機命名型網站集合,但若有適用下列任一條件的情況,則應該使用傳統路徑型網站集合和備用存取對應:

  • 您必須使用屬於 SharePoint Server 2016 預設安裝一部分的自助網站架設功能。

    這不適用於自訂自助網站架設解決方案。

  • Web 應用程式需要唯一的包含相對路徑或包含絕對路徑。

    您可以在伺服器陣列層級建立主機命名型網站集合的包含路徑,這些路徑可供所有主機名稱網站使用。伺服器陣列中的所有主機命名型網站集合會共用相同的包含路徑,但不需要使用這些路徑。相反地,您為路徑型網站集合建立的包含路徑只會套用至單一 Web 應用程式。

  • 需要 SSL 終止,但是無法設定您的 SSL 終止裝置以產生必要的自訂 HTTP 標頭。

    如果不需要 SSL 終止,您仍然可以使用 SSL 橋接主機命名型網站集合與這些裝置。

  • 您要規劃使用不同的應用程式集區以取得這些應用程式集區所提供的額外安全性,否則您需要使用多個 Proxy 群組。

如需包括和路徑型網站集合進行比較在內的主機命名型網站集合詳細資訊,請參閱<SharePoint Server 中已指定主機的網站集合架構與部署>。

網站集合的設計目標

網站集合可銜接邏輯架構和資訊架構。網站集合的設計目的,是要滿足 URL 設計需求,以及建立內容的邏輯分隔。針對每個網站集合,管理路徑會加入頂層網站集合的第二層。如需 URL 需求及使用管理路徑的詳細資訊,請參閱本文稍後的<區域及 URL>。在網站集合第二層之下,每個網站都是子網站。

下圖說明「小組網站」的網站層級。

小組網站的網站階層

小組網站

針對路徑型網站集合和主機名稱集合,資訊架構會以網站集合第二層為主。下列各節說明設計範例如何根據網站本質做出選擇。

已發佈的內部網路內容

對於已發佈的內部網路內容 Web 應用程式,將假設公司內多個部門將主控已發佈內容。在設計範例中,會由不同的網站集合主控每個部門的內容。這樣做有下列好處:

  • 每個部門可單獨管理內容及管理權限。

  • 每個部門可在專用資料庫中儲存其內容。

多個網站集合的缺點包括:

  • 您無法跨網站集合共用主版頁面、頁面配置、範本、網頁組件及導覽方式。

  • 協調不同網站集合的自訂和導覽需要更多心力。

根據內部網路網站的所有資訊架構及設計,已發佈內容可以向使用者呈現為一個無縫體驗。或者,每個網站集合也可以呈現為單獨網站。

我的網站

「我的網站」具有特殊特性,且「我的網站」的部署建議十分簡單。在設計範例中,「我的網站」網站集合所用頂層網站的 URL 為 http://my。所建立的第一個頂層網站集合使用「我的網站主機」範本,而且使用管理路徑 (即使用包含相對路徑),如此可允許使用者建立無限多個網站。所有在管理路徑之下的網站均為使用「個人網站」範本的獨立網站集合。URL 最後會加上使用者名稱,格式為 http://my personal/username。下圖說明「我的網站」。

「我的網站」的網站階層

我的網站

小組網站

您可以使用下面其中一種方式來設計「小組網站」應用程式中的網站集合:

  • 允許小組透過自助網站架設方式來建立網站集合。此方式的優點,在於小組可以視需要輕鬆建立網站,而不需要管理員的協助。此方式的缺點包括:

    • 無法實作完善規劃的分類。

    • 無法讓可能共用網站集合的專案或小組共用範本及導覽方式。

  • 根據組織運作方式,為組織建立有限的網站集合。在此方法中,SharePoint 管理員會建立網站集合。建立網站集合後,小組可以在網站集合中建立網站。此方式可實作完善規劃的分類,提供因應小組網站在管理及成長上的結構。其中還提供許多方式可讓共用網站集合的專案及小組共用範本及導覽方式。但是,此方法也包含下列缺點:

設計範例採用的是第二種方式,這會使小組網站與已發佈內部網路內容具有類似的網站集合階層。資訊架構師的挑戰就在於建立適合組織的網站集合第二層。下表建議不同的組織類型。

表:建議的網站集合分類

組織類型 建議的網站集合分類

產品開發

  • 為開發中的每項產品建立網站集合。允許參與小組在網站集合中建立網站。

  • 針對每個長期開發專案,為參與產品工作的每個大型小組,建立網站集合。例如,為下列每個小組建立一個網站集合:設計者、工程師和內容開發人員。

研究

  • 為每個長期研究專案建立網站集合。

  • 為每種類別的研究專案建立網站集合。

高等教育機構

  • 為每個學術部門建立網站集合。

國家立法機構

  • 為每個政黨建立網站集合。同屬一個政黨的政府官員可以共用範本及導覽方式。

  • 為每個委員會建立網站集合。或者,為所有委員會建立一個網站集合。

企業法律事務所

  • 為企業客戶建立網站集合。

製造

  • 為每個產品線建立網站集合。

合作夥伴 Web 應用程式

合作夥伴網站主要用於針對設有一定範圍或一定時限的專案,與外部合作夥伴進行共同作業。根據設計,合作夥伴 Web 應用程式內的各個網站不會彼此相關。合作夥伴 Web 應用程式的需求包括必須確保下列事項:

  • 專案擁有者可以輕鬆建立合作夥伴共同作業的網站。

  • 合作夥伴及其他參與者只能存取他們所處理的專案。

  • 網站擁有人管理權限。

  • 搜尋某個專案所得的結果不會公開其他專案的內容。

  • 管理員可以輕易識別出不再使用的網站,並刪除這些網站。

為滿足這些需求,在設計範例中,每個專案各有一個網站集合。這兩種公司入口網站設計範例都使用管理路徑,在根網站集合下建立網站集合的第二層。或者,外部網路設計範例可以使用主機命名型網站集合,將每個合作夥伴網站設為頂層網站集合。不論哪種方式,個別網站集合都可讓專案之間有適當的隔離層級。

如果您想使用屬於 SharePoint Server 預設安裝一部分的自助網站架設功能 (相對於為組織開發的自訂解決方案),請使用路徑型網站集合。主機命名型網站集合還無法使用此功能。

內容資料庫

您可以使用下列兩種方式,在設計中加入內容資料庫 (設計範例即同時使用這兩種方式):

  • 為具有適當大小警告閾值的內容資料庫建立目標大小。在資料庫達到大小警告閾值時,建立新的資料庫。使用此方式,會僅根據大小目標值,自動將網站集合新增至可用的一或多個資料庫。這是最常用的方式。

  • 建立網站集合與特定內容資料庫的關聯。此方式可讓您將一或多個網站集合放入管理員可以與其他資料庫分開管理的專用資料庫。

若選擇將網站集合關聯至特定內容資料庫,則可以使用下列方法來完成:

  • 使用 PowerShell 在特定資料庫中建立網站集合。

  • 套用下列資料庫容量設定,讓資料庫專用於單一網站集合:

    • 警告事件產生前的網站數目 = 1

    • 此資料庫中可以建立的最大網站數目 = 1

  • 完成下列步驟,將網站集合群組新增至專用資料庫:

    1. 在 Web 應用程式中,建立資料庫,並將資料庫狀態設為 [就緒]。

    2. 將所有其他資料庫的狀態設定為 [離線]。內容資料庫離線時,無法建立新的網站集合。但是,讀取與寫入作業仍可存取離線資料庫中的現有網站集合。

    3. 建立網站集合。它們會自動新增至資料庫。

    4. 將所有其他資料庫的狀態設回 [就緒]。

已發佈的內部網路內容

對於已發佈的內部網路內容,公司入口網站設計範例僅使用單一資料庫,以便於管理。如有需要,請根據目標大小值新增資料庫。

我的網站

對於「我的網站」,公司入口網站設計範例藉由管理資料庫達到目標大小上限,而獲得規模效益。為達到此目的,設定了下列設定:

  • 限制網站儲存量的最大值為:此設定 (在管理中心的「配額範本」頁面上設定) 可限制個人網站大小。

  • 第二階段資源回收筒:此設定 (在「Web 應用程式一般設定」頁面上設定) 可決定還需要額外配置給第二階段資源回收筒的空間量。

  • 這個資料庫可以建立的網站數目上限:此設定是在您建立資料庫時設定。請根據您在前面兩項所指定的值,來計算總共可允許的網站大小。然後,根據每個資料庫的大小目標,決定資料庫可容納的網站數目。

在設計範例中,根據 175 GB 的資料庫目標大小和 1 GB 的「我的網站」目標大小,提供了下列範例大小設定:

  • 每個網站的網站大小限制 = 1 GB

  • 資料庫目標大小 = 175 GB

  • 保留給第二階段資源回收筒使用的空間 = 15%

  • 網站數目上限 = 180

  • 網站層級警告 = 150

達到網站層級警告時,會建立新的資料庫。建立新的資料庫之後,新的「我的網站」會新增至具有最少網站集合的內容資料庫。

小組網站

大多數組織的小組網站應會遠大於「我的網站」。小組網站是建立在受管理路徑底下,每個小組網站集合可各有一個內容資料庫。在設計範例中,所提供的資料庫設定是以 30 GB 的網站集合限制為根據。請為您組織的小組網站選擇適當限制。

合作夥伴網站

類似「我的網站」,合作夥伴網站藉由管理資料庫達到目標大小上限,而獲得規模效益。

此設計範例提供了下列範例大小設定:

  • 資料庫目標大小 = 200 GB

  • 每個網站的儲存配額 = 5 GB

  • 網站數目上限 = 40

  • 將製作網站集合架設在專用資料庫中

區域及 URL

設計範例說明如何在公司部署中協調多個網站之間的 URL。下列目標會影響 URL 的設計決策:

  • URL 慣例不限制使用者藉以存取內容的區域。

  • 在設計範例中,標準 HTTP 及 HTTPS 連接埠 (80 及 443) 可用於所有應用程式。

  • URL 不包括連接埠號碼。實際上,連接埠號碼一般不會用於實際執行環境。

設計負載平衡 URL

在建立 Web 應用程式時,您必須選擇負載平衡 URL 以指派給該應用程式。您選擇的 URL 會套用至「預設」區域。此外,還必須為每個在 Web 應用程式中建立的額外區域建立負載平衡 URL。負載平衡的 URL 包括通訊協定、配置、主機名稱及連接埠 (若有使用)。在所有 Web 應用程式及區域中,負載平衡 URL 必須是唯一的。因此,每個應用程式及每個應用程式中的每個區域,在整個設計範例中都需使用唯一的 URL。

內部網路

構成內部網路的三個網站集合都需使用唯一的 URL。在公司入口網站設計範例中,內部網路內容的目標對象包括內部員工及遠端員工。無論員工位於公司內部還是位於遠端,他們對這些網站都使用相同 URL。雖然此方法會讓 SharePoint 設計多一層安全性 (因為所有流量都屬於 SSL),不過此方法需要您選擇其他設定的替代方法:

  • 透過防火牆或閘道產品路由內部流量及遠端流量。

  • 設定分割 DNS 環境,以在內部網路中解析內部要求。

合作夥伴網站

在設計範例中,內部員工、遠端員工及合作夥伴員工會存取合作夥伴網站。在公司入口網站設計範例中,所有使用者都輸入相同 URL,無論所用的驗證方法為何。在外部網路設計範例中,不同類型使用者分別輸入不同 URL。雖然個別合作夥伴及合作夥伴公司都是使用 SSL (HTTPS) 從外部存取合作夥伴網站,每一組人員還是需要不同 URL 才能享受到不同區域 (亦即,不同驗證方法及不同區域原則) 的好處。

由於外部網路設計範例使用直接存取或 VPN 進行遠端員工存取,因此遠端員工和內部員工都使用相同的 URL。如果透過反向 Proxy 裝置設定遠端員工存取,則遠端員工需要使用 SSL 的個別 URL,因此需要額外的區域。最後,外部網路設計範例使用主機命名型網站集合,而不是單一頂層網站集合。因此,每個專案網站會有不同的 URL。

下表顯示內部員工、遠端員工及合作夥伴存取合作夥伴網站所用的範例 URL,如外部網路設計範例所示。

表:外部網路設計範例的範例 URL

區域 範例 URL

內部及遠端員工

http://project1

不同的合作夥伴

https://project2.fabrikam.com

合作夥伴公司

https://TrustedPartnerProject1.fabrikam.com

在 URL 路徑中使用包含絕對路徑及包含相對路徑

管理路徑可讓您指定 Web 應用程式之 URL 命名空間中用於網站集合的路徑。您可以指定在根網站的不同路徑下有一個或多個網站集合。若沒有管理路徑,所有在根網站集合下的網站都會是根網站集合的一部分。

您可以建立下列兩種類型的管理路徑:

  • **包含絕對路徑:**指派具有明確 URL 的網站集合。一個包含絕對路徑只能套用至一個網站集合。您可以在根網站集合下建立許多包含絕對路徑。使用此方法建立的網站集合 URL 範例為 http://intranet/hr。每個新增的包含絕對路徑都會影響效能,因此,建議您使用包含絕對路徑建立的網站集合限制在 20 個左右。

  • **包含相對路徑:**新增至 URL 的路徑。此路徑表示緊跟在路徑名稱後所指定的所有網站,都是唯一的網站集合。此選項常用於支援自助網站架設的網站集合 (例如「我的網站」)。使用此方法建立的網站集合 URL 範例為 http://my/personal/user1。

實作主機命名型網站集合的管理路徑時,會在伺服器陣列層級建立這些管理路徑,且如果解決方案中包含多個 Web 應用程式,這些路徑會套用至所有 Web 應用程式。實作路徑型網站集合的管理路徑時,這些管理路徑只會套用至建立管理路徑的 Web 應用程式。

設計範例同時使用這兩種管理路徑類型 (包含絕對路徑和包含相對路徑),如下列各節所述。

包含絕對路徑:已發佈的內部網路內容

在設計範例中,已發佈的內部網路網站集合針對每個子網站 (例如,HR、設備和採購) 使用包含絕對路徑。這些網站集合都可以與不同內容資料庫產生關聯 (如有需要)。除非使用主機命名型網站集合,否則在此範例中使用包含絕對路徑,係假設 Web 應用程式中沒有建立其他類型的網站,包括包含相對路徑。

使用包含絕對路徑會產生下列 URL:

在此範例中,根網站集合 http://intranet.fabrikam.com 代表內部網路的預設首頁。此網站預定會主控使用者的內容。

包含相對路徑:小組網站、「我的網站」及合作夥伴網站

小組網站、「我的網站」及合作夥伴 Web 應用程式使用包含相對路徑。包含相對路徑適用於允許使用者建立其自己的網站集合的應用程式,也適用於包含大量網站集合的 Web 應用程式。包含相對路徑表示萬用字元後面的下一個項目是網站集合的根網站。

小組網站

在小組網站應用程式內,每個小組網站集合皆使用包含相對路徑。良好的控管作法建議將頂層小組網站數目保持在可管理的數目內。此外,小組網站的分類邏輯應該配合公司運作方式。

使用包含相對路徑會產生下列 URL:

在此範例中,根網站集合 https://teams.fabrikam.com 不一定主控使用者的內容。

我的網站

「我的網站」提供自助網站架設。瀏覽內部網路的使用者第一次按一下 [我的網站] 時,會自動為使用者建立「我的網站」。在設計範例中,「我的網站」使用包含相對路徑 /personal (http://my/personal)。「我的網站」功能會自動在 URL 的最後加上使用者名稱。

這會產生下列格式的 URL:

合作夥伴網站

如果使用路徑型網站集合,您可以實作自助網站架設功能,以讓員工建立可與外部合作夥伴共同作業的安全網站。如果使用主機命名型網站集合,您可以實作自訂自助網站架設功能,或管理員可以在要求下建立合作夥伴專案網站。

在公司入口網站設計範例中,合作夥伴 Web 應用程式包括包含相對路徑 /sites (http://partnerweb/sites)。這會產生下列格式的 URL:

使用 AAM 和 DNS 協調 URL

如果實作路徑型網站集合,請為伺服器陣列中的每個網站 URL 設定備用存取對應 (AAM)。如此可確保 Web 要求對應至正確的網站,特別是在使用負載平衡或反向 Proxy 技術的環境中。

您可以為內部網路存取設定單一名稱 URL (例如 http://teams)。用戶端電腦會透過附加其 DNS 尾碼 (例如 fabrikam.com),然後發出具有該尾碼之名稱的 DNS 查閱,來解析這些 URL。例如,當 fabrikam.com 網域中的用戶端電腦要求 http://teams 時,電腦會將 http://teams.fabrikam.com 的要求傳送至 DNS。

您必須設定 DNS,才可以針對每個完整網域名稱 (FQDN) 使用 A 記錄 (或適用於 IPv6 的 AAAA)。此記錄會指向架設網站之網頁伺服器的負載平衡 IP 位址。在一般的實際執行部署中,除了 DNS 中靜態指派的 A 或 AAAA 記錄之外,您還可以設定伺服器使用靜態指派的 IP 位址。

用戶端瀏覽器收到負載平衡 IP 位址之後,用戶端瀏覽器會連線至伺服器陣列中的前端網頁伺服器,然後傳送具有原始單一名稱 URL (http://teams) 的 HTTP 要求。IIS 和 SharePoint Server 會根據在備用存取對應中進行的設定,將此要求辨識為內部網路區域的要求。如果使用者改為要求 https://teams.fabrikam.com,程序會類似,不同之處在於 IIS 和 SharePoint Server 會收到此 FQDN,因此會將此要求辨識為「預設」區域的要求。

在具有多個網域的環境中,輸入網站所在以外的網域 DNS 的 CNAME 記錄。例如,如果 Fabrikam 網路環境包含第二個網域 europe.fabrikam.com,則會輸入歐洲網域之網站的 CNAME 記錄。針對小組網站的內部網路網站 (http://teams),會將名為 teams 的 CNAME 記錄新增至 europe.fabrikam.com 網域,以指向 teams.fabrikam.com。然後,當用戶端電腦的 DNS 尾碼附加至 DNS 查閱要求時,來自歐洲網域的 http://teams 要求會發出 teams.europe.fabrikam.com 的 DNS 查閱,再由 CNAME 記錄導向至 teams.fabrikam.com。

注意

某些使用 Kerberos 驗證的用戶端及解析 CNAME 記錄有已知問題。如需詳細資訊,請參閱<Kerberos configuration known issues (SharePoint Server 2010)>。

區域原則

您可以設定一或多個區域的原則,以對 Web 應用程式中的所有內容強制執行權限。在宣告模式中,只能針對特定區域定義原則 (而不是針對一般的 Web 應用程式)。原則可強制執行使用者透過區域存取所有內容的權限。原則權限會覆寫針對網站和內容設定的其他所有安全性設定。您可以根據使用者或使用者群組來設定原則,但不能根據 SharePoint 群組設定原則。如果新增或變更區域原則,搜尋必須重新編目網站,才能套用新的權限。

由於單一區域上已啟用多種驗證類型,以及 (或) 所有網站包含在一個 Web 應用程式中,因此設計範例不會使用原則。