應用服務器集羣與兵馬俑

Question

我聽說過用於GlassFish等應用服務器以及Terracotta的術語「集羣」我試圖理解什麼集羣意味着當與應用服務器結合使用時，並與兵馬俑一起使用時。

我瞭解是：

如果GlassFish服務器集羣，那麼就意味着我們有多個物理/虛擬機，每個都有自己的JRE/JVM上運行的GlassFish的不同實例。但是，由於它們是羣集的，它們都將通過其管理服務器（「DAS」）進行通信，並將相同的應用程序部署到它們全部。他們將有效地（對最終用戶）採取行動，就好像他們是單個應用程序服務器一樣 - 但現在具有負載均衡，故障轉移/冗餘和可擴展性。

Terracotta本質上是一種產品，它使多個JVM在不同的物理/虛擬機上運行，​​就好像它們是單個JVM一樣。

因此，如果我的理解是正確的，以下是暗示：

• 您集羣應用服務器，當你想負載平衡和故障容忍
• 您可以使用兵馬俑時，任何特定的JVM是太小，無法包含你的應用程序和你需要更多的「馬力」
• 因此，從技術上講，如果你有一個GlassFish集羣，比如5個服務器實例，這5個實例中的每一個實際上都可能是一個數組/集羣的兵馬俑實例;這意味着每個GlassFish服務器實例實際上都是跨越多臺機器的JVM的GlassFish實例本身

如果這些斷言/假設中的任何一個不真實，請糾正我！如果我已經離開基地並且明顯不瞭解集羣和/或兵馬俑的目的，請指出我的方向。

Answer 1

Terracotta使您可以在所有節點（其有狀態）中擁有共享狀態。基本上它會在不同的JVM之間創建一個共享內存空間。當集羣中的節點都需要訪問相同的對象時，這非常有用。

如果您的應用程序是無狀態的，並且您只需要負載平衡並進行故障轉移，則可以使用像JGroups這樣的解決方案。在這種情況下，每個節點只處理請求，而對其他節點沒有多少想法。內存中的對象不是跨節點共享的，每個JVM都是獨立運行的，並且不知道其他JVM的情況。這通常適用於請求/響應類型的應用程序。提供內容的網絡服務器（沒有會話）就是這樣做的。

處理無狀態羣集通常比處理有狀態羣集更簡單。這是因爲在一個無狀態的集羣中，節點幾乎不瞭解對方，導致可能出錯的東西減少。

GlassFish位於上述概念的中間。 GlassFish中內存中的對象對所有節點均可見。然而，前端（HTTP連接器）工作在無狀態。

因此，要回答你的問題：

1）是的，那些是兩個最明顯的原因。但是有時候人們只想要故障轉移，或者只想要負載均衡或者有時候都需要。並非所有的集羣解決方案都能解決這兩個問題。

2）是的。從技術上講，Terracotta只能解決共享內存部分，而不是CPU部分。然而，通過解決內存部分，它會自動解決CPU部分，因爲您現在可以將JVM添加到共享內存空間。

3）我不知道這是否實際上可能，但作爲一個思想實驗;是。

Answer 2

集羣可以指下列之一：

1. 多個實例可以作爲一個管理。將應用程序部署到羣集，它將部署到羣集中的所有實例。更改配置，並將該更改推送到集羣中的所有節點。 GlassFish支持開箱即用。
2. 服務可用性。如果任何一個實例失敗，該應用程序在另一個實例上可用。沒有啓用高可用性，任何實例故障也會導致由該實例管理的任何會話都會丟失會話。 GlassFish支持開箱即用。
3. 高可用性。如果任何一個實例失敗，則應用程序在另一個實例和上可用，因爲會話副本也在另一個實例上維護，所以沒有會話丟失。 GlassFish支持這一點。您將不得不在任何一個羣集中選擇＃2或＃3。

你對於恕我直言的問題真的是＃3，因爲它是Terracotta - 在高可用性集羣環境下 - 將提供具有GlassFish價值的唯一真實案例。 GlassFish已經提供了內置的高可用性，所以最好有一個很好的理由將Terracotta添加到解決方案中，因爲它會使部署架構複雜化。

我可以考慮添加Terracotta的主要原因是您可能希望將會話管理卸載到數據網格並釋放GlassFish以運行業務邏輯。這可能是由於更頻繁的垃圾收集或想要爲每個GlassFish實例管理更多用戶。但是，我不確定兵馬俑可以無縫地做到這一點。藉助GlassFish內置HA羣集，複製會話是無縫的（無需應用程序邏輯修改）。您可能需要編寫代碼才能從Terracotta緩存中獲取/獲取數據我會讓您研究:-) Oracle GlassFish Server還與Coherence集成（無縫地）以解決此問題。您可以將會話管理分離爲Coherence數據網格，而無需修改應用程序代碼。除非您事先知道您的應用程序必須擴展到大量的併發用戶，否則請從內置HA集羣開始，運行測試並從此處開始。

希望這會有所幫助。