受管理的儲存區

適用於：Exchange Server 2013

從 Exchange Server 4.0 到 Exchange Server 2010 的所有舊版 Exchange Server 都支援在信箱伺服器角色上執行資訊存放區進程 (Store.exe) 的單一實例。 這個單一 Store 實例會裝載伺服器上的所有資料庫：主動、被動、延遲和復原。 在先前的 Exchange 架構中，信箱伺服器上裝載的不同資料庫之間幾乎沒有隔離。 單一信箱資料庫的問題可能會對所有其他資料庫造成負面影響，而信箱損毀所造成的損毀可能會影響該伺服器上裝載資料庫之所有用戶的服務。

舊版 Exchange 中單一 Store 實例的另一項挑戰是，可延伸儲存引擎 (ESE) 可調整為 8-12 個處理器核心，但超過該臨界值，跨處理器通訊和快取同步處理問題會導致負規模。 假設現今的伺服器有16個以上的核心系統可用，這意謂著管理ESE 8-12核心的同構型，以及針對非市集程式使用其他核心， (例如Assistants、Search Foundation、受控可用性等 ) 的系統管理挑戰。 此外，先前的架構會限制市集程序的相應增加。

隨著 Exchange Server 本身的演進，Store.exe 程式在這幾年已大幅演進，但作為單一進程，其延展性最終會受到限制，且代表單一失敗點。 由於這些限制，Store.exe 在 Exchange 2013 中已消失，並由受控存放區取代。

受管理的儲存區

受控存放區是資訊存放區 (的名稱，也稱為 2013 Exchange Server 中的 Store) 進程。 受控存放區使用控制器/背景工作進程模型，可提供記憶體進程隔離和更快速的資料庫故障轉移。 受控存放區也包含新的靜態資料庫快取機制，可取代舊版 Exchange Server 中的動態緩衝區演算法。 在受控存放區所使用的多進程模型中，在此案例中，有單一存放區服務控制器進程 (，Microsoft.Exchange.Store.Service.exe 也稱為 MSExchangeIS) ，而在此案例中，有一個背景工作進程 (，每個掛接的資料庫 Microsoft.Exchange.Store.Worker.exe) 。 掛接資料庫時，會具現化新的背景工作進程，只服務該資料庫。 卸除資料庫時，該資料庫的背景工作進程會終止。

例如，如果您在伺服器上掛接了 40 個資料庫，則會有 41 個進程針對受控存放區執行，一個用於每個資料庫，一個用於存放區服務進程控制器。

存放服務進程控制器是精簡且可靠的，但如果停止或終止，其所有背景工作進程都會消失 (他們會偵測到服務控制器進程已消失並結束) 。 存放區進程控制器會監視伺服器上所有存放區背景工作進程的健康情況。 Microsoft.Exchange.Store.Service.exe 導致所有作用中資料庫複本的立即故障轉移，這是無法或非預期的終止。 受控存放區也與 Microsoft Exchange 複寫服務 (MSExchangeRepl.exe) 和 Active Manager 緊密整合。 控制器進程、背景工作進程和復寫服務會一起運作，以提供更高的可用性和可靠性：

• Microsoft Exchange 複寫服務程式 (MSExchangeRepl.exe)

  • 負責對市集發出掛接和卸除作業

  • 針對存放區、可延伸儲存引擎 (ESE) 和受控可用性回應者所報告的記憶體或資料庫失敗起始復原動作

  • 偵測非預期的資料庫失敗

  • 提供管理工作的系統管理介面

• 儲存服務進程/控制器 (Microsoft.Exchange.Store.Service.exe)

  • 根據從復寫服務接收的掛接和卸除作業，管理每個背景工作進程存留期

  • 處理來自 Windows 服務控制管理員的傳入要求

  • 記錄在偵測到存放背景工作進程問題時的失敗專案 (例如，停止回應或非預期的結束)

  • 在回應故障轉移事件中終止存放區背景工作進程

• 存放背景工作進程 (Microsoft.Exchange.Store.Worker.exe)

  • 負責在資料庫上執行信箱的 RPC 作業

  • 背景工作進程內的 RPC 端點實例是資料庫 GUID

  • 提供資料庫的資料庫快取

靜態資料庫快取演算法

Exchange 2000 Server、Exchange Server Exchange Server 2003、Exchange Server 2007 和 2010 Exchange Server 2010 中資訊存放區所引進的資料庫快取演算法，稱為動態緩衝區配置，也稱為 2010 Exchange Server。 Exchange 2013 使用簡單且直接的演算法來判斷資料庫快取。 發生故障轉移時，受控存放區不會再動態重新配置資料庫之間的快取，這可大幅簡化內部快取管理。 相反地，配置給每個資料庫快取的記憶體 (例如，每個存放區背景工作進程) 會根據本機資料庫複本數目和 MaximumActiveDatabases 的值設定。 如果 MaximumActiveDatabases 的值大於目前資料庫複本的數目，則快取計算是以資料庫複本數目為基礎。

Exchange 2013 所使用的靜態演算法會根據實體 RAM，為每個存放區背景工作進程的 ESE 快取配置記憶體。 此記憶體稱為資料庫的最大 快取目標。 總伺服器記憶體的 25% 會配置給 ESE 快取。 此比例的記憶體稱為 「伺服器快取大小目標」。

此快取的靜態數量會配置給主動和被動複本。 只有在服務使用中資料庫複本時，才會配置存放區背景工作進程的最大快取目標。 被動資料庫複本會配置最大快取目標的 20%。 其餘部分由市集保留，如果資料庫從被動轉換為主動，則會配置給背景工作進程。

[最大快取目標] 只會在 Store 啟動時計算。 因此，如果您新增或移除資料庫或資料庫複本，您必須重新啟動 Store 控制器服務 (MSExchangeIS) ，以便據以調整快取。 如果未重新啟動服務，則新建立的資料庫的快取大小目標會比服務啟動之前建立的資料庫小。 在此情況下，資料庫快取大小目標的總和可能會超過伺服器快取大小目標，直到 MSExchangeIS 重新啟動為止。

範例資料庫快取計算

以下是以信箱伺服器的記憶體和資料庫組態為基礎的資料庫快取計算範例。

範例 1

在此範例中，信箱伺服器有 48 GB 的記憶體，並裝載兩個作用中資料庫和兩個被動資料庫。 此外，未設定 MaximumActiveDatabases 參數。 在此設定中，每個作用中資料庫複製背景工作進程的資料庫快取量為 3 GB，而每個被動資料庫複製背景工作進程的資料庫快取量為 0.6 GB。 以下是取得這些值的方式。

若要取得伺服器快取大小目標，請將記憶體數量乘以 25%，

48 GB X 25% = 12 GB

若要取得資料庫最大快取目標，請將伺服器快取大小目標除以主動和被動資料庫的總數：

12 GB / 4 個資料庫 = 3 GB

若要判斷被動資料庫複本所使用的記憶體數量，請將資料庫最大快取目標乘以 20%

3 GB X 20% = 0.6 GB

在指派給伺服器快取大小目標的 12 GB 記憶體中，資料庫背景工作進程會使用 7.2 GB，而資訊存放區會保留 4.8 GB，以供兩個被動資料庫複本使用，以防它們變成使用中複本。 在此情況下，他們會使用其最大快取目標 3 GB。

範例 2

在此範例中，信箱伺服器也有 48 GB 的記憶體，並裝載兩個作用中資料庫和兩個被動資料庫;不過， MaximumActiveDatabases 參數設定為 2。 在此設定中，每個作用中資料庫複製背景工作進程的資料庫快取量為 5 GB，而每個被動資料庫複製背景工作進程的資料庫快取量為 0.2 GB。 以下是取得這些值的方式。

若要取得伺服器快取大小目標，請將記憶體數量乘以 25%，

48 GB X 25% = 12 GB

若要取得資料庫最大快取目標，請將伺服器快取大小目標除以使用中資料庫總數加上被動資料庫總數乘以 20%，

12 GB / (2A + (2P X 20%) ) = 5 GB

若要判斷被動資料庫複本所使用的記憶體數量，請將資料庫最大快取目標乘以 20%

5 GB X 20% = 1 GB

在指派給伺服器快取大小目標的 12 GB 記憶體中，資料庫背景工作進程會使用 12 GB，而且資訊存放區不會保留這兩個被動資料庫複本的記憶體，因為此組態 (無法成為使用中複本，因為 MaximumActiveDatabases 的值設定為 2， 而且伺服器) 上已經有 2 個作用中的資料庫複本。