專利名稱：服務器陣列容量管理計算器的制作方法
技術領域：
本發明涉及計算機系統，尤其涉及服務器陣列容量管理計算器系統和方法。
背景技術：
諸如游戲門戶、搜索引擎等許多基于web的應用從服務器場被提供至最終用戶。 這些服務器場包括不同類型的服務器的陣列，不同類型的服務器被配置為響應最終用戶的各種類型的請求。隨著服務的用戶數量增長，服務器場中的服務器數量也可增長。這樣的服務器場的管理員所面對的一個困難是隨著用戶基礎的增長，難以估計將需要多少服務器來滿足用戶請求的負載。部署的服務器太多是昂貴而且浪費的，而部署的服務器太少則可能導致性能問題，而且使用戶不滿意，特別是在峰值需求期間。

發明內容
提供了服務器陣列容量管理計算器系統和方法。例如，提供一種用于基于所觀察的診斷數據估計服務器陣列容量的系統，該系統包括數據庫和估計器計算設備。估計器計算設備可包括圖形用戶界面和由處理器使用部分存儲器執行的并包括從多個不同服務器類型的服務器接收診斷數據以及經由圖形用戶界面接收用戶輸入的指令的容量管理模塊。 響應于用戶輸入且對于各服務器類型，容量管理模塊可被配置為基于當前服務器效率估計和已使用的服務器的當前數量來計算服務器的當前參考數量，基于用戶的計劃數量和當前并發用戶的計數之比來計算增長倍數，通過將服務器的當前參考數量與增長倍數相乘產生服務器的計劃數量，并在圖形用戶界面上顯示服務器的計劃數量。提供本發明內容是為了以精簡的形式介紹將在以下具體實施方式
中進一步描述的一些概念。本發明內容并不旨在標識出所要求保護的主題的關鍵特征或必要特征，也不旨在用于限定所要求保護的主題的范圍。此外，所要求保護的主題不限于解決在本發明的任一部分中提及的任何或所有缺點的實現。


圖1示出了用于根據本發明的實施例計算服務器陣列容量的估計系統。圖2示出了根據本發明的實施例的圖形用戶界面。圖3示出了圖2所示圖形用戶界面的實施例的一部分。圖4示出了圖2所示圖形用戶界面的實施例的另一部分。圖5示出了根據本發明的實施例的一種方法的流程圖。
具體實施例方式對基于服務器的網絡計算基礎結構的預測容量計劃可提供一致的用戶體驗而不管服務規模的改變，諸如當服務增長時。在一些服務場景中，服務使用可與服務器利用率相關。由此，當更多的用戶提出不斷增長的服務需求時，服務器基礎結構可更努力地工作以支
4持不斷增長的需求。此外，需求可能并非均勻地分布在服務器基礎結構中；一些服務器類型可能比其他服務器類型更努力地工作。例如，在一個場景中，一交互式游戲服務的峰值并發使用負載可被預測為在即將到來的假日周末可能預計有一百萬用戶，其中估計20%的使用將針對多媒體下載活動， 70%將針對玩游戲而10%將針對社交網絡。在該場景中，這些活動中的每一個可招致游戲服務的不同的事務成本。事務成本可以在原子級與服務器處理器利用率相關，盡管比如服務器存儲器利用率、服務器盤速度以及服務器輪詢速率之類的其他事務成本也可以適用。 例如，與社交網絡活動相比，多媒體下載活動可以具有較大的事務成本，并可以使用更多服務器處理器時間。盡管這些示例性事務成本可根據活動而變化，但在各種活動之間可以具有一致的關系。例如，歷史數據可以提供多媒體下載活動和社交網絡活動之間的經驗關系， 使得前者中的增量式活動增長通常轉換為后一活動中的相關變化。由此，提供了一種用于基于在服務上所觀察到的診斷數據對于計劃數量的服務用戶計算服務器陣列容量的估計系統。圖1示出了用于計算服務器陣列容量的估計系統100的實施例。估計系統100包括服務器陣列102、收集器計算設備108、估計器計算設備122、顯示器130和數據庫112。在一個實施例中，如將在下文中更詳細描述的，系統可以實現在在線游戲服務的服務器陣列中。服務器陣列102包括多個服務器104。服務器104可根據服務器類型105被安排在服務器陣列102中。例如，在線游戲服務可包括一個或多個用于提供用戶化身的化身服務器、一個或多個用于提供在線游戲的游戲服務器、一個或多個用于提供在線零售物品的市場服務器，和/或一個或多個用于提供在線電影的電影服務器。僅舉數例，其他示例性服務器類型包括但不限于，在場服務器、游戲應用服務器、web服務服務器、連接服務器、安全網關服務器、統計數據服務器、高速緩存服務器，以及診斷服務器。每一服務器104包括診斷程序106，用于收集和/或存儲關于服務器使用的各種診斷數據。例如，在一些實施例中，診斷程序106可以收集當前并發用戶的計數的數據。在一些實施例中，診斷數據可由包括在診斷程序106中的一個或多個工作計數器模塊和/或資源監視模塊來檢測。此外，在一些實施例中，診斷程序106可以測量服務器效率。例如，診斷程序106 可以為每一服務器測量規格化的事務效率或處理器效率。此外，在一些實施例中，診斷程序106可為每一服務器104收集當前事務速率數據，諸如每單位時間所請求的事務數量的計數和/或每單位時間所提供的事務數量的計數。如圖1所示，從每一服務器104收集的診斷數據被報告給收集計算設備108。收集計算設備108包括用于收集各種診斷數據并將其存儲在數據庫112中的收集器程序110。 在一些實施例中，收集計算設備108也可以將診斷數據報告給數據庫112，診斷數據例如為服務器陣列102內正被使用的每一服務器類型105的服務器104的當前數量以及分配至每一服務器類型105的服務器104的當前數量。例如，診斷數據可包括當前專用于化身服務器的10個服務器的計數。另外地或另選地，在一些實施例中，可為每一服務器類型105計算平均當前處理器最大負載數據，并將其包括在存儲于數據庫112中的診斷數據中。
在圖1所示的示例中，數據庫112為每一服務器類型105，在每服務器的基礎上以每單位時間當前事務的計數的形式，比如每服務器當前每秒事務數(TPQ 114、當前處理器利用率116、當前并發用戶的數量的計數118，以及使用的服務器的當前數量的計數120，來存儲當前事務速錄數據。由此，在一個場景中，數據庫112的檢查可以指示，對于化身服務器類型，每一服務器處理每服務器100TPS ；每一化身服務器具有30%的處理器利用率；兩百萬并發用戶當前正在使用該服務；以及有10個化身服務器。數據庫112也可對于一個或多個其他服務器類型包含類似數據。圖形用戶界面132被呈現在顯示器130上。圖形用戶界面132接收用戶輸入134 和顯示輸出142。用戶輸入134被配置為接收容量計劃所基于的一個或多個參數。用戶輸入134可包括并發用戶的計劃數量138和/或目標服務器效率136。在一些實施例中，用戶輸入134可包括對應于處理器利用率閾值的處理器閾值輸入135。這可以避免服務器縮放“曲棍”行為，該行為指示出處理器利用率和事務請求之間不可預測的關系。例如，盡管運行在處理器閾值輸入135以下的服務器可以展示事務速率和用戶數量之間的可預測的關系(如線性關系)，但是對于許多服務器，在處理器閾值輸入 135以上的操作可能導致事務速率和用戶數量間不可預測的關系，這可能對服務器性能和服務器容量計劃產生不利影響。在一些實施例中，處理器閾值輸入135可根據服務器類型來指定。例如，用戶可以指定第一服務器類型的處理器可具有為60%的第一處理器閾值輸入，而第二服務器類型可具有為90 %的第二處理器閾值輸入。另外地或另選地，在一些實施例中，對于第一類型服務器的第一處理器閾值輸入的用戶指定可使對應于不同類型服務器的不同處理器閾值可通過程序方式來被提供至容量管理模塊128。例如，可以知道第一處理器閾值具有與第二服務器類型的處理器閾值的可預測的關系。由此，一個處理器閾值的用戶指定可使另一處理器閾值根據該可預測的關系而通過編程方式來被指定。在一些實施例中，用戶輸入134可包括關于容量計劃將基于在用戶指定的時間/ 天/日期范圍140內(例如，最近30天)或用戶指定的日期范圍(例如，從3/1/2010到 5/1/2010)所收集的診斷數據的一個或多個指定。此外，在一些實施例中，用戶可以指定診斷數據將根據包括在時間/天/日期范圍140中的周中的某一天和/或一天里的某一個時間鍵來進行過濾(例如，使用在周末或某一天晚上所收集的診斷數據，排除在周末的7PM到 IOPM期間所收集的診斷數據，選擇在定義的假期期間所收集的診斷數據，等等)。估計器計算設備122包括存儲在部分存儲器1 中的并在處理器IM上執行的容量管理模塊128。估計器計算設備122從圖形用戶界面132接收用戶輸入134，以及從數據庫112接收診斷數據，并產生容量計劃信息以用于在圖形用戶界面132上顯示。響應于接收到用戶輸入134，容量管理模塊1 基于當前服務器效率巧4和已使用的服務器的當前數量120來為每一服務器類型105計算服務器的當前參考數量。在一些實施例中，服務器的當前參考數量可以表示能夠服務用戶需求的服務器104的理論最小數量。在一些實施例中，容量管理模塊1 可以基于當前處理器利用率116和處理器輸入閾值135來估計當前服務器效率154。例如，可以通過將當前處理器利用率116除以處理器閾值輸入135來估計當前服務器效率。由此，在10個化身服務器中的每一個的當前處理器利用率為30%而處理器閾值輸入為60%的一個場景中，每一化身服務器將具有的當前化身服務器效率為50%。在一些實施例中，容量管理模塊1 可以基于當前服務器效率巧4和每服務器基礎上的當前事務速率數據來估計每服務器當前服務器事務速率閾值。例如，在一些實施例中可以通過將每服務器當前TPS 114除以當前服務器效率IM來估計每服務器當前服務器事務速率閾值。由此，繼續上面所描述的化身服務器場景，如果每一化身服務器處理100 TPS并且當前化身服務器效率為50%，那么每化身服務器當前事務速率閾值為每化身服務器 200 TPS。每服務器當前服務器事務速率閾值然后可以被用于計算服務器的當前參考數量。 例如，在一個場景中，可以通過將已使用的服務器的當前數量120和每服務器當前TPS 114 的乘積除以每服務器當前服務器事務速率閾值來計算服務器的當前參考數量。由此，在化身服務器場景中，基于當前使用的10個化身服務器、每化身服務器當前100 TPS以及每化身服務器當前事務速率閾值為200 TPS，化身服務器的當前參考數量將為5。容量管理模塊1 還基于用戶的計劃數量138和當前并發用戶的數量118之比來計算增長倍數。例如，在一些實施例中，可以通過將并發用戶的計劃數量138除以當前并發用戶8的數量118來計算增長倍數。由此，繼續化身服務器場景，如果當前計數為兩百萬的并發用戶計劃將增長到四百萬并發用戶，那么增長倍數將為2。容量管理模塊1 進一步通過將服務器的當前參考數量與增長倍數相乘來產生對于計劃數量的并發用戶138將部署在服務器陣列102中的服務器的計劃數量146。服務器的計劃數量146然后經由圖形用戶界面132被顯示在顯示器130上。例如，對于以上所描述的化身場景，為滿足60%處理器閾值的計劃需求所需要的計劃數量的化身服務器將為 10個化身服務器。由此，用戶可以決定不購買另外的化身服務器，因為10個化身服務器已被建立。在一些實施例中，容量管理模塊1 可以基于當前服務器效率巧4和服務器的計劃數量144來估計計劃服務器效率。例如，對于以上所描述的場景計劃化身服務器效率將為100%。此外，在一些實施例中，容量管理模塊1 可以經由圖形用戶界面132顯示警告 152，警告當前服務器效率IM和/或計劃服務器效率是在目標服務器效率136以內的或是超出目標服務器效率136 —預定義的控制界限137。在一些實施例中，容量管理模塊1 可以基于包括在用戶輸入134中的處理器閾值輸入135、并發用戶的計劃數量138和增長被修改的處理器估計來計算對于服務器陣列 102中每一不同服務器類型105可服務的并發用戶的最大數量144。該增長被修改的處理器估計可以基于每一服務器類型的平均當前處理器最大負載數據和增長倍數來產生。并發用戶的最大數量144然后可經由圖形用戶界面132被顯示在顯示器130上。圖2中示出了圖形用戶界面132的示例性實施例。在本示例中，用戶已在時間/天 /日期范圍140指定當在計劃將要部署的服務器數量時，3/1/2010和5/1/2010之間的所有天數的診斷數據都將被使用。此外，在目標服務器效率136和并發用戶的計劃數量138輸入處，用戶已指定服務器陣列102將運行在60%效率等級并在計劃服務器數量所針對的時間服務290萬并發用戶。圖形用戶界面132還呈現包括服務器的計劃數量136、計劃處理器負載148和計劃TPS/服務器150的輸出142。在一些實施例中，輸出142也可以包括并發用戶的最大數量 144和/或警告152。示例性輸出142呈現在圖2的表IA和IB中，并分別在附圖3和4中詳細示出。 在一些實施例中，輸出142可以根據預定優先級來呈現。例如，圖3示出了多個優先級標識符301，用于向用戶標識一個或多個服務器類型105的服務器104的相對優先級。在圖 3所示的示例中，根據本示例中有狀態和無狀態服務器的相對優先級，第一優先級標識符 301A(標記為有狀態的)優先于第二優先級標識符301B(標記為無狀態的)。但是，可以理解，在一些實施例中，可以不同地配置優先級區分或可根本不提供優先級區分。此外，在一些實施例中，相對優先級區分可以是用戶可配置的或可以通過程序方式來配置。例如，對于每一服務器類型105，圖3示出了以下輸出當前服務器效率154(標記為效率)、對分配給每一服務器類型105的服務器104的當前數量的已分配服務器計數 302 (標記為已分配的服務器)、對所使用的服務器104的當前數量的已使用服務器計數 120(標記為已使用的服務器)、在當前服務器以其最滿容量被使用的情況下將服務當前負載的服務器的計算出的當前參考數量304(標記為所需的當前服務器)、用于服務計劃數量的并發用戶138的計劃服務器負載的服務器的計劃數量146(標記為所需的增長被修改的服務器)，以及每服務器當前TPS114 (標記為當前TPS/服務器)。如以上所描述的，服務器效率154、已分配的服務器計數302和已使用的服務器計數由診斷程序106確定。服務器的當前參考數量304由容量管理模塊1 來計算，并表示如果組中的每一服務器都以其最滿容量被使用那么將用于服務每服務器當前TPS負載的服務器的估計數量。例如，以下等式可以被用于計算服務器的當前參考數量。服務器的當前參考數量=“每服務器當前TPS”/ “TPS服務器閾值”* “已使用的服務器”每服務器當前TPS 114通常由配置在每一服務器上的計數器來測量，該計數器測量每秒或每其他單位時間接收到的請求、每秒接收到的批處理請求等。根據以下等式，服務器的計劃數量146可以通過首先按等式來計算每秒增長被修改的事務，然后將結果乘以增長倍數來計算。每秒增長被修改的事務=“當前TPS/服務器” * “增長倍數”服務器的計劃數量=“當前TPS/服務器” / “TPS/服務器閾值” * “已使用的服務
JJJl ”
益現在轉向圖4，對于表內各行中每一服務器類型105，表IB示出了每服務器計劃事務速率148 (標記為增長被修改的TPS/服務器)、每服務器當前事務速率閾值402 (標記為 TPS/服務器閾值)、平均當前處理器最大負載404(標記為當前平均最大CPU)、計劃處理器負載148 (標記為增長被修改的CPU)、處理器閾值輸入135 (標記為CPU閾值)、以及并發用戶的最大數量144 (標記為最大可支持⑶)。每服務器計劃事務速率148可以如以上所描述的對每秒增長被修改的事務來計算。每服器事務速率閾值402可以根據以下公式來計算。每服務器事務速率閾值=("CPU閾值，，/ “平均最大CPU+1STDEV”)* “當前TPS/ 服務器”其中CPU閾值是對相關服務器類型標識的度量，而當前TPS/服務器是由為服務器類型105的每個服務器部署的計數器測量的每服務器每秒平均當前事務。如這里和本發明的其他地方所使用的，平均最大+1標準差(ISTDEV)表示某一度量的最大值的平均與同一度量的樣本的標準差相加。由此，如以上所描述的，平均最大CPU 使用+ —個標準差表示在已觀察的時間段中的平均最大CPU使用+ —個標準差。例如，如果五個服務器的最大CPU使用為50 %、55 %、50 %、50 %和75 %，那些服務器的平均最大CPU 使用將為56%而那些服務器的最大CPU使用的標準差將大約為10. 8 %，使得平均最大CPU 使用+ —個標準差將大約為66. 8%。該方法可以提供比替換方法更好的利用率度量，替換方法例如為將利用率設定為那些服務器的絕對最大CPU使用的定義比例(在一些示例中例如為95% )。例如，對于以上所描述的五個服務器，絕對最大為75%，因而絕對最大的95% 為(在本示例中，75%的95%大約為)71. 2%。由此，可以理解，可能是離群值的值75%，按照平均最大+—個標準差的方法比按照絕對最大的定義比例的方法對利用率度量造成的偏斜更小。但是，可以理解，平均最大+ —個標準差的方法僅是一個示例性方法，而且其他適當的示例(包括絕對最大的定義比例的方法)可以用于本實施例的范圍內。平均當前處理器最大負載404 (標記為當前平均最大CPU)可以根據以下等式來計算當前平均最大CPU = “處理器、％處理器時間、總數”的最大值的平均+1STDEV，其計算了所測量的處理器使用、處理器時間的最大值的平均，并加在相關測量的一個標準差的所選平均上。計劃處理器負載148 (標記為增長被修改的CPU)可以計算如下增長被修改的CPU = “當前平均最大CPU”* “增長倍數”，其中當前平均最大CPU和增長倍數如以上所描述的來計算。處理器閾值輸入135(標記為CPU閾值)通常為由用戶輸入至圖形用戶界面132 的處理器閾值輸入域中的值，如圖2所示，其指示了所需的最大處理器效率，用戶希望服務器陣列中特定服務器類型的服務器運行在該最大處理器效率上。可以理解，處理器閾值輸入135對于每一服務器類型105可以不同，例如如表IB的第一行和第二行中不同的處理器閾值輸入值所示。并發用戶的最大數量144可以由容量管理模塊1 根據以下等式來計算。該值表示在每一服務器以其最滿容量來被使用的情況下計劃數量的服務器能夠支持的用戶的最大數量。最大可支持并發用戶=“在該時間段內的最大并發用戶” / “所需的當前服務器” * “已使用的服務器”。圖5示出了用于為不同服務器類型的服務器陣列計算服務器陣列容量的一種方法500的實施例。例如，在一個場景中，服務器陣列中的服務器類型可以包括化身服務器、 游戲服務器、市場服務器或電影服務器中的兩種或更多。盡管方法500在以下參考以上所描述的硬件和軟件來描述，但可以理解的是，方法500可以使用任何適當的硬件和軟件來實現。方法500包括，在502，在執行于估計器計算設備上的容量管理模塊處，經由圖形用戶界面接收用戶輸入，該用戶輸入包括用戶的計劃數量。在一些實施例中，在502處接收用戶輸入可包括，在504，經由圖形用戶界面接收
9日期范圍輸入、周中的某一天輸入、一天里的某一個時間輸入、并發用戶的計劃數量輸入、 預定義控制界限輸入、目標服務器效率輸入和/或處理器閾值輸入。在506，方法500包括從服務器陣列中的不同服務器類型的多個服務器接收診斷數據。對于每一服務器類型，診斷數據可以包括已使用的服務器的當前數量、當前并發用戶的計數和當前處理器利用率數據。例如，在一個場景中，診斷數據可以由執行于服務器陣列中每一服務器上的工作計數器模塊和/或資源監視模塊來檢測，并存儲在數據庫中。在一些實施例中，在506處接收診斷數據可以包括，在508，針對日期范圍輸入、周中的天輸入和/或一天中的時間輸入過濾診斷數據。在510，方法500包括，響應于用戶輸入以及對于每一服務器類型，基于當前服務器效率估計和已使用的服務器的當前數量來計算服務器的當前參考數量。在一些實施例中，在510處計算服務器的當前參考數量可以包括，在512，基于當前服務器效率估計和當前事務速率數據估計當前服務器事務速率閾值。例如，在一個場景中，當前事務速率數據可以包括每單位時間所請求的事務數量的計數和/或每單位時間所服務的事務數量的計數。在514，方法500包括，響應于用戶輸入以及對于每一服務器類型，基于用戶的計劃數量和當前并發用戶的計數之比計算增長倍數。在516，方法500包括，響應于用戶輸入以及對于每一服務器類型，通過將服務器的當前參考數量與增長倍數相乘產生將為計劃數量的用戶部署在服務器陣列中的服務器的計劃數量。在一些實施例中，方法500可以包括，在518，基于包括于用戶輸入中的處理器閾值輸入、用戶的計劃數量和增長被修改的處理器估計來計算對于服務器陣列中每一不同服務器類型能夠被服務的并發用戶的最大數量。例如，在一個場景中，增長被修改的處理器估計可以基于每一服務器類型的平均當前處理器最大負載數據并基于增長倍數來產生，其中平均當前處理器最大負載數據包括在診斷數據中。繼續，在520，方法500包括在圖形用戶界面上顯示服務器的計劃數量。在一些實施例中，方法500可以包括，在522，在圖形用戶界面上顯示并發用戶的最大數量。以上所描述的系統和方法可以被實現來高效地管理服務器陣列的容量計劃，從而滿足服務器負載期望，同時潛在地避免了服務器資源的過部署或部署不足。可以理解，此處所描述的計算設備和服務器可以是被配置成執行此處所描述的程序的合適的計算設備。例如，計算設備可以是大型計算機、個人計算機、膝上型計算機、便攜式數據助理(PDA)、啟用計算機的無線電話、聯網計算設備，或其他合適的計算設備，并可以經由諸如因特網等計算機網絡彼此連接。這些計算設備通常包括處理器和相關聯的易失性和非易失性存儲器，以及諸如硬盤驅動器等大容量存儲設備。這些計算設備被配置為使用部分易失性存儲器和處理器來執行存儲在非易失性存儲器中的程序，以實現此處所描述的功能。例如，計算設備可以配置有比如鍵盤、鼠標和觸摸屏之類的用戶輸入設備，并進一步可以配備有顯示器。此外，如此處所使用的，術語“程序”和“模塊”表示可以由此處描述的一個或多個計算設備執行或利用的軟件或固件組件，并且意味著包括下述一項或多項可執行文件、數據文件、庫、驅動程序、腳本、數據庫記錄等。可以理解，可提供具有存儲在其上的程序指令的計算機可讀介質，當由計算設備執行時，所述指令使得計算設備執行上述方法，并且使得上述系統工作。計算機可讀介質可以包括存儲器設備，例如隨機存取存儲器(RAM)、只讀存儲器(ROM)、硬盤、緊致盤(CD)、數字視頻盤(DVD)等。此處所描述的程序和模塊中的一些或全部可以是軟件模塊或硬件組件，例如存儲器設備。可以理解，如此處所使用的“服務”可以是在多個用戶會話之間可執行的應用程序，而且對于其他操作系統組件和應用來說是可用的。服務可以響應于客戶端的請求而運行在服務器上。應該理解，此處所述的配置和/或方法在本質上示例性的，且這些具體實施例或示例不是局限性的，因為多個變體是可能。此處所述的具體例程或方法可表示任何數量的處理策略中的一個或多個。由此，所示出的各個動作可以按所示順序執行、按其他順序執行、并行地執行、或者在某些情況下省略。同樣，可以改變上述過程的次序。本發明的主題包括各種過程、系統和配置的所有新穎和非顯而易見的組合和子組合、和此處所公開的其它特征、功能、動作、和/或特性、以及其任何和全部等效物。
權利要求
1.一種用于計算服務器陣列容量的估計系統(100)，包括數據庫(112)，用于存儲由執行在服務器陣列(10 的每一服務器(104)上的工作計數器模塊(106)和資源監視模塊(106)所檢測的診斷數據；以及估計器計算設備(122)，包括圖形用戶界面(13 和由處理器(124)使用部分存儲器 (126)執行的容量管理模塊(1 )，所述容量管理模塊(128)包括執行以下操作的指令從服務器陣列中的不同服務器類型的多個服務器接收診斷數據，對于每一服務器類型，所述診斷數據包括已使用的服務器的當前數量(120)和當前并發用戶的計數(118)；經由所述圖形用戶界面接收用戶輸入(134)，所述用戶輸入包括用戶的計劃數量 (138)；以及響應于所述用戶輸入以及對于每一服務器類型基于當前服務器效率估計(154)和所述已使用的服務器的當前數量來計算服務器的當前參考數量，基于所述用戶的計劃數量和所述當前并發用戶的計數的比率來計算增長倍數，通過將所述服務器的當前參考數量與所述增長倍數相乘，產生對于所述計劃數量的用戶將被部署在所述服務器陣列中的服務器的計劃數量(146)，以及在所述圖形用戶界面上顯示所述服務器的計劃數量。
2.如權利要求1所述的系統，其特征在于，計算服務器的當前參考數量的指令進一步包括基于所述當前服務器效率估計和包括在所述診斷數據中的當前事務速率數據來估計當前服務器事務速率閾值的指令。
3.如權利要求2所述的系統，其特征在于，所述當前事務速率數據包括每單位時間所請求的事務數量的計數和/或每單位時間所服務的事務數量的計數。
4.如權利要求1所述的系統，其特征在于，所述診斷數據包括當前處理器利用率數據， 所述診斷數據由執行在所述服務器陣列中的每一服務器上的工作計數器模塊和資源監視模塊來檢測并被存儲在數據庫中。
5.如權利要求1所述的系統，其特征在于，所述服務器陣列中的服務器類型包括以下中的兩種或多種化身服務器、游戲服務器、市場服務器或電影服務器或其他類型的服務器至客戶端連接陣列。
6.如權利要求1所述的系統，其特征在于，所述容量管理模塊進一步包括對于每一服務器類型執行以下操作的指令基于包括在所述用戶輸入中的處理器閾值輸入、基于所述用戶的計劃數量和基于增長被修改的處理器估計來計算對于所述服務器陣列中每一不同服務器類型能夠被服務的并發用戶的最大數量；以及在所述圖形用戶界面上顯示所述并發用戶的最大數量。
7.如權利要求6所述的系統，其特征在于，所述增長被修改的處理器估計是基于每一服務器類型的平均當前處理器最大負載數據和所述增長倍數來產生的，所述平均當前處理器最大負載數據包括在所述診斷數據中。
8.如權利要求1所述的系統，其特征在于，所述容量管理模塊進一步包括經由所述圖形用戶界面接收日期范圍輸入、周中的天輸入和/或一天中的時間輸入的指令，所述接收所述診斷數據包括針對所述日期范圍輸入、周中的天輸入和/或一天中的時間輸入過濾所述診斷數據。
9.一種用于計算服務器陣列的容量的方法(500)，包括，在執行于估計器計算設備上的容量管理模塊上從服務器陣列中的不同服務器類型的多個服務器接收(506)診斷數據，對于每一服務器類型，所述診斷數據包括已使用的服務器的當前數量和當前并發用戶的計數；經由圖形用戶界面接收(50 用戶輸入，所述用戶輸入包括用戶的計劃數量；以及響應于所述用戶輸入以及對于每一服務器類型基于當前服務器效率估計和所述已使用的服務器的當前數量來計算(510)服務器的當前參考數量，基于所述用戶的計劃數量和所述當前并發用戶的計數的比率來計算(514)增長倍數，通過將所述服務器的當前參考數量與所述增長倍數相乘，產生(516)對于所述計劃數量的用戶將被部署在所述服務器陣列中的服務器的計劃數量，以及在所述圖形用戶界面上顯示(520)所述服務器的計劃數量。
10.如權利要求9所述的方法，其特征在于，計算服務器的當前參考數量進一步包括基于所述當前服務器效率估計和包括在所述診斷數據中的當前事務速率數據來估計當前服務器事務速率閾值。
11.如權利要求10所述的方法，其特征在于，所述當前事務速率數據包括每單位時間所請求的事務數量的計數和/或每單位時間所服務的事務數量的計數。
12.如權利要求9所述的方法，其特征在于，進一步包括，對于每一服務器類型基于包括在所述用戶輸入中的處理器閾值輸入、基于所述用戶的計劃數量和基于增長被修改的處理器估計來計算對于所述服務器陣列中每一不同服務器類型能夠被服務的并發用戶的最大數量；以及在所述圖形用戶界面上顯示所述并發用戶的最大數量。
13.如權利要求12所述的方法，其特征在于，所述增長被修改的處理器估計是基于每一服務器類型的平均當前處理器最大負載數據和所述增長倍數來產生的，所述平均當前處理器最大負載數據包括在所述診斷數據中。
14.如權利要求9所述的方法，其特征在于，進一步包括經由所述圖形用戶界面接收日期范圍輸入、周中的某一天輸入和/或一天中的某一時間輸入，接收所述診斷數據包括針對所述日期范圍輸入、周中的天輸入和/或一天中的時間輸入過濾所述診斷數據。
15.如權利要求9所述的方法，其特征在于，所述診斷數據包括當前處理器利用率數據，所述診斷數據由執行在所述服務器陣列中的每一服務器上的工作計數器模塊和資源監視模塊來檢測并被存儲在數據庫中。
全文摘要
本發明涉及服務器陣列容量管理計算器。提供了用于基于診斷數據估計容量的服務器陣列容量計算器系統和方法。例如，一種系統，包括數據庫和估計器計算設備，該估計器計算設備包括圖形用戶界面(GUI)和存儲在存儲器中并執行在處理器上的容量管理模塊，該容量管理模塊包括指令用于從不同服務器類型的多個服務器接收診斷數據，經由GUI接收用戶輸入，并響應于該用戶輸入以及對于每一服務器類型，從當前服務器效率和已使用的服務器的當前數量計算服務器的當前參考數量；從用戶的計劃數量和當前并發用戶的計數之比計算增長倍數；通過將服務器的當前參考數量與增長倍數相乘產生服務器的計劃數量，并在GUI上顯示服務器的計劃數量。
文檔編號H04L29/08GK102263659SQ201110170750
公開日2011年11月30日 申請日期2011年6月13日 優先權日2010年6月14日
發明者G·霍根, R·Y·馬 申請人:微軟公司