payara 创建 集群_高可用性（HA），会话复制，多VM Payara群集
payara 創建 集群
抽象
在研究如何創建高可用性（HA）時，我發現了會話復制，多機處理的Payara / GlassFish群集，無法在單個參考中找到所需的一切。 我認為這將是一個普遍的需求并且很容易找到。 不幸的是，我的假設是錯誤的。 因此，本文的目的是給出一個完整的端到端示例，說明高可用性（HA），會話復制，多機Payara群集。 但我也（幾乎）說，因為與任何技術一樣，我敢肯定還有其他方法可以做到這一點。 這篇文章中描述的方式來自我的研究。
要求
我使用以下主要技術完成了本文的所有工作。 您可能可以使用不同的技術或版本來做相同的事情，但不能保證。
- Java SE 8 – OpenJDK 1.8.0_91
- Java EE 7 – Payara 4.1.1.163
- VirtualBox 5.1.6
- 魯本圖16.04
- Nginx 1.10.0
- NetBeans 8.2
- Maven 3.0.5（與NetBeans捆綁在一起）
定義
在這篇文章中，以下詞語將具有這些特定含義。 這里不需要律師，但最好確定定義。
機器 ：機器一詞指的是正在運行其自己的操作系統的東西。 它可以是真正的硬件，例如筆記本電腦，臺式機，服務器或樹莓派。 也可以是運行在VirtualBox或VMWare之類的VM。 也可以是看起來像Docker容器之類的機器的東西。
群集 ：群集是GlassFish Server實例的集合，這些實例作為一個邏輯實體一起工作。 群集為一個或多個Java平臺企業版（Java EE）應用程序提供了運行時環境（管理GlassFish Server群集，nd）
群集節點 ：群集節點代表安裝了GlassFish Server軟件的主機。 GlassFish Server實例所在的每個主機必須存在一個節點（管理GlassFish Server節點，nd）
群集節點實例 ：GlassFish Server實例是運行GlassFish Server的單個節點上Java平臺（Java虛擬機或JVM機器）的單個虛擬機。 JVM計算機必須與Java平臺企業版（Java EE）兼容。 （管理GlassFish服務器實例，nd）
建筑
由于這篇文章描述了跨多臺計算機的Payara集群，因此了解每臺計算機在集群中將扮演什么角色非常重要。 沒有計劃就開始在多臺計算機上安裝軟件是不明智的。 本節將概述：
這篇文章不會介紹機器的實際啟動和運行方式。 這是您的任務。 一些選項是：真實硬件（Raspberry Pi），虛擬機（Virtual Box），容器（Docker）或云（AWS）。 如果您已經有啟動，運行，配置并準備就緒的計算機，則可以跳過本節，直接跳至“ 集群創建” 。
架構圖
圖1顯示了為本文構建的簡單示例應用程序的簡單架構圖。 但是，即使很簡單 ，擁有它也很重要。 它可以防止在機器上隨機安裝軟件，直到您“正確安裝”為止。 另外，這里使用的重要單詞很簡單 。 該體系結構包含此示例所需的最少內容。 它絕不是全面的或生產就緒的。 因此，考慮到這一點，下一步是更詳細地研究此體系結構的各個部分。
圖1 –“ Z區”圖
圖1 –“ Z區”圖區域：S應該為網絡中的所有計算機分配一個區域。 區域將執行相似功能的計算機組合在一起，還定義了區域之間的計算機如何相互通信。 本示例顯示了Zone S 該區域將用于支持應用程序服務的機器。
srv [N] .internal.dev藍色框表示該區域中的計算機。 區域中的每臺計算機都應明確定義角色，并且最好不要讓計算機承擔太多角色。 該區域的計算機名為srv[N].internal.dev 。 srv表示該機器是Zone S的服務機器部分。 [N]唯一標識機器。 最后，域.internal.dev表示這是在開發環境中內部訪問的計算機。 在“ 計算機角色”部分中介紹了每臺計算機的角色 。
群集橙色框代表區域內的群集。 該集群將使用Payara構建。 框中應包含所有參與群集的計算機。
群集管理器，群集實例，負載平衡器黃色框代表計算機上正在運行的內容。 機器的角色決定了機器上運行的東西。 接下來，您可以查看計算機的角色。
機器角色
那么， Zone S每臺計算機上正在運行什么？ 再次參考圖1，機器角色如下：
現在已經清楚了每臺機器的作用，接下來要看的是機器之間的通信。
機器網絡配置
名稱srv01 ， srv02和srv03將是計算機的簡短主機名。 每臺計算機上/etc/hostname的內容將具有此名稱。 這是srv01的主機名：
$ cat /etc/hostname srv01.internal.dev是這些計算機的域。 機器應能夠通過短主機名或完全合格的主機名相互通信。
注意此域– .internal.dev –稍后對于在群集中正確配置WAR以實現高可用性會話復制至關重要。
最簡單的方法是通過/etc/hosts 。 （在區域中的所有計算機上）將/etc/hosts配置為包含短主機名和標準主機名。
$ cat /etc/hosts 127.0.0.1 localhost 10.0.2.16 srv01.internal.dev srv01 10.0.2.17 srv02.internal.dev srv02 10.0.2.18 srv03.internal.dev srv03應該使用簡單的ssh測試來驗證所有計算機之間的通信。 不要跳過此驗證。 Payara將使用SSH進行通信，因此最好在Payara嘗試使用它之前對其進行驗證和故障排除。 我將把進行此測試的詳細信息留給您。
現在所有機器都可以相互通信，接下來要看的是機器上的Linux用戶帳戶。 不太令人興奮，但非常重要。
機器用戶配置
每臺機器都需要一個payara用戶，該用戶的主目錄位于/home/payara 。 payara用戶用于運行Payara。 沒有任何內容應以root身份運行。 很簡單。
現在您已經掌握了機器配置的基礎知識，現在該開始創建Payara集群了。
集群創建
使用Payara可以輕松創建集群。 當使用單獨的機器時（相反，典型的示例使用同一臺機器來完成所有操作）有一些其他步驟。 本節將概述：
本節嚴格專注于創建和配置集群。 這意味著在閱讀本節之后，您將擁有一個群集，但這并不意味著您的應用程序已準備就緒，可以進行高可用性和會話復制。 下一節將討論WAR配置 。 現在該開始構建集群了。
Payara安裝
Payara的安裝無非就是下載ZIP文件并將其解壓縮。 當然，請轉到Payara并找到下載頁面。 這篇文章使用Payara 4.1.1.163。 現在該在該區域中的所有計算機上安裝Payara了。
- 下載Payara 4.1.1.163
- 將Payara解壓縮到/home/payara 。 這將創建/home/payara/payara41 。
- 創建一個符號鏈接$ln -s payara41 active
- 將Payara bin目錄放在payara Linux用戶的$PATH 。 /home/payara/.bashrc添加到/home/payara/.bashrc ：
做完了！ 很簡單。 接下來查看Payara域是否可以啟動。
Payara域名啟動
使用asadmin工具啟動Payara域。 在srv01.internal.dev上執行以下命令。
payara$ asadmin start-domain domain1如果一切順利，該域將啟動。 通過瀏覽到http：// localhost：4848來驗證它是否已啟動并正在運行。 Payara的默認配置沒有保護DAS的用戶名/密碼，因此您應該立即登錄。現在DAS正在運行，接下來要做的就是一些安全性配置。
Payara DAS安全配置
現在是時候配置集群中機器之間通信所需的一些安全性了。 所有這些命令都在srv01.internal.dev上執行。
注意所有這些配置也可以通過Payara GUI管理員應用程序http：// localhost：4848來完成，但這并不好玩！ 命令行很有趣，希望可以實現自動化。
asadmin密碼更改默認的Payara asadmin密碼。 第一次執行此命令時，請記住Payara沒有默認的用戶名/密碼，因此當提示輸入密碼時，請將其留空。 在srv01.internal.dev上執行以下命令：
payara@srv01$ asadmin change-admin-password Enter admin user name [default: admin]>admin Enter the admin password> // Keep this blank when executing this for the first time Enter the new admin password> // Create a new password Enter the new admin password again> // Enter new password again重新啟動域，以確保所做的更改。 在srv01.internal.dev上執行以下命令：
payara@srv01$ asadmin restart-domain domain1現在，使用asadmin登錄到DAS，以驗證用戶名/密碼。 以下命令將登錄DAS，并且在登錄后可以執行asadmin命令， 而無需每次都輸入用戶名/密碼。 這是一種便利，但當然會帶來安全風險。 要登錄，請在srv01.internal.dev上執行以下命令：
payara@srv01$ asadmin login Enter admin user name [Enter to accept default]> admin Enter admin password> *******Login information relevant to admin user name [admin] for host [localhost] and admin port [4848] stored at [/home/payara/.gfclient/pass] successfully. Make sure that this file remains protected. Information stored in this file will be used by administration commands to manage associated domain.Command login executed successfully.安全管理員現在，您要在群集內啟用安全通信。 這基本上意味著Payara DAS將與群集實例安全地通信。 此步驟不是必需的，但是幾乎總是很高興。 在srv01.internal.dev上執行以下命令：
payara@srv01$ asadmin enable-secure-admin重新啟動域，以確保所做的更改。 在srv01.internal.dev上執行以下命令：
payara@srv01$ asadmin restart-domain domain1安全配置就是這樣。 下一步是在嘗試開始創建集群之前，驗證從區域中的計算機到DAS的通信。
Payara DAS通信驗證
嘗試不跳過此步驟。 大多數人希望正確地進行集群構建并跳過驗證步驟。 這樣可以節省一些時間，但是，如果某些操作不正常，則在驗證步驟中更容易解決問題。 到目前為止，啟動和配置DAS的所有工作都在srv01 。 現在驗證機srv02和srv03能夠與在DAS溝通srv01 。
在srv02.internal.dev上執行以下操作，并驗證結果，如圖所示。
payara@srv02$ asadmin --host srv01 --port 4848 list-configs Enter admin user name> admin Enter admin password for user "admin"> server-config default-config Command list-configs executed successfully.在srv03.internal.dev上執行以下操作，并驗證結果，如圖所示。
payara@srv03$ asadmin --host srv01 --port 4848 list-configs Enter admin user name> admin Enter admin password for user "admin"> server-config default-config Command list-configs executed successfully.在srv02和srv03上成功執行將驗證那些機器可以與srv01上的DAS成功通信。 現在已經驗證了這一點，是時候創建集群了。
集群創建
現在將要創建集群。 對于此示例，該群集將被巧妙地命名為c1 。 通常，應該適當地命名集群，但是，對于此示例， c1可以很好地工作。 在srv01.internal.dev上執行以下srv01.internal.dev 。
payara@srv01$ asadmin create-cluster c1 Command create-cluster executed successfully.而已！ 很抗氣候吧？ 集群在那里，但是里面什么也沒有。 現在是時候用節點填充集群了。 沒有節點，集群不是很有用。
集群節點創建
群集節點將位于機器srv02和srv03 。 但是，創建節點的命令在srv01上執行。 在srv01執行時， asadmin工具將使用ssh將必需的文件傳輸到srv02和srv03 。 為了方便起見，首先創建一個臨時密碼文件以使SSH更容易。
臨時密碼文件記得在每臺計算機上都創建了payara Linux用戶。 這是運行Payara以避免以root用戶運行Payara的普通Linux用戶。 臨時密碼文件包含srv02和srv03上的payara Linux用戶的未加密密碼。 假定payara用戶的Linux密碼在所有計算機上都相同。 如果不是這種情況，則在嘗試在srv[N]上創建節點之前，將需要使用機器srv[N]上的payara用戶的正確密碼來更新臨時密碼文件。
注意也可以使用RSA / DSA密鑰文件。 有關更多信息，請參考create-node-ssh文檔。 http://docs.oracle.com/cd/E18930_01/html/821-2433/create-node-ssh-1.html#scrolltoc
上創建集群節點srv02要在創建節點srv02 ，上執行以下命令srv01.internal.dev 。
payara@srv01$ echo "AS_ADMIN_SSHPASSWORD=[clear_text_password_of_payara_usr_on_srv02]" > /home/payara/passwordpayara@srv01$ asadmin create-node-ssh --nodehost **srv02.internal.dev** --sshuser payara --passwordfile /home/payara/password srv02-node上創建集群節點srv03要在創建節點srv03 ，上執行以下命令srv01.internal.dev 。
payara@srv01$ echo "AS_ADMIN_SSHPASSWORD=[clear_text_password_of_payara_usr_on_srv03]" > /home/payara/passwordpayara@srv01$ asadmin create-node-ssh --nodehost **srv03.internal.dev** --sshuser payara --passwordfile /home/payara/password srv03-node刪除臨時密碼文件創建所有節點后，不再需要臨時密碼文件。 此時可以將其刪除。 當然，如果將更多計算機添加到群集中，并且需要更多節點，則可以輕松創建另一個臨時密碼文件。
Payara@srv01$ rm /home/payara/password因此，現在您有了一個群集和節點。 節點很棒。 但是，沒有實例，節點無法做任何事情。 能夠運行應用程序的是節點上的實例。 這是實際的Payara實例。 因此，現在該制作一些集群節點實例了。
群集節點實例創建
創建節點實例基本上是在節點上創建Payara實例。 一個節點上可以有許多實例。 這完全取決于機器的資源。 節點實例將在srv02和srv03的節點中創建。 但是，用于創建節點實例的命令在srv01上執行。 在srv01執行時， asadmin工具將在srv02和srv03上創建節點實例。
創建節點實例srv02上創建2個節點實例srv02 。 節點實例將稱為srv02-instance-01和srv02-instance-02 。 在srv01.internal.dev上執行以下命令：
payara@srv01&$ asadmin create-instance --cluster c1 --node srv02-node srv02-instance-01Command _create-instance-filesystem executed successfully. Port Assignments for server instance srv02-instance-01: ..... The instance, srv02-instance-01, was created on host srv02 Command create-instance executed successfully.payara@srv01$ asadmin create-instance --cluster c1 --node srv02-node srv02-instance-02Command _create-instance-filesystem executed successfully. Port Assignments for server instance srv02-instance-02: ..... The instance, srv02-instance-02, was created on host srv02 Command create-instance executed successfully.如果在執行完這些命令后，在控制臺上顯示了“成功執行命令創建實例”消息，那么可以確信一切正常。 但是，您應該驗證以確保。 驗證過程在srv02和srv03 。 成功的驗證意味著找到/nodes目錄。 在srv02.internal.dev上執行以下srv02.internal.dev 。
payara@srv02$ cd /home/payara/active/glassfish payara@srv02$ ls bin common config domains legal lib modules nodes osgi創建節點實例srv03上創建2個節點實例srv03 。 進行與上一個標題完全相同的所有操作，但使用srv03而不是srv02 。
現在有4個Payara實例…
分布在2個節點上...
在2臺不同的機器上…
在1個邏輯Payara群集上
現在，開始一切！
集群啟動
啟動集群c1確實非常容易。 這是通過srv01計算機完成的，當DAS啟動所有群集實例時，請注意控制臺以確保所有4個實例都已啟動。 在srv01.internal.dev上執行以下命令。
payara@srv01$ asadmin start-cluster c1 0%: start-cluster: Executing start-instance on 4 instances. Command start-cluster executed successfully.集群運行后，通過在DAS中列出正在運行的集群來驗證集群是否正在運行。 通過在DAS中列出實例來驗證節點實例是否正在運行。在srv01.internal.dev上執行以下命令。
payara@srv01$ asadmin list-clusters c1 running Command list-clusters executed successfully.payara@srv01$ asadmin list-instances srv02-instance-01 running srv02-instance-02 running srv03-instance-01 running srv03-instance-02 running Command list-instances executed successfully.恭喜你！ 您現在有了一個不錯的4實例集群。 現在是時候部署應用程序了嗎？ 錯誤！ 在部署應用程序之前，重要的是要驗證節點之間的多播網絡通信是否正常工作，以允許HttpSession在整個集群中復制。 接下來驗證多播網絡通信。
集群多播驗證
擁有集群的全部目的是擁有一個高可用性，會話復制的應用程序。 如果一個實例有問題，群集中的另一個實例（可能在另一個節點上）將無縫接管。 但是，為了使這種情況真正發生，群集實例必須能夠彼此成功通信。 Payara有validate-multicast工具對此進行了測試。 但是，訣竅在于如何運行validate-multicast 。 為了成功運行， validate-multicast ，必須在兩個運行srv02和srv03 AT同一時間 ！ 執行以下的srv02.internal.dev 和 srv03.internal.dev 在同一時間 （哈夫納，2011）！
srv02.internal.dev在srv02.internal.dev上執行以下srv02.internal.dev ：
payara@srv02$ asadmin validate-multicast Will use port 2048 Will use address 228.9.3.1 Will use bind interface null Will use wait period 2,000 (in milliseconds)Listening for data... Sending message with content "srv02" every 2,000 milliseconds Received data from srv02 (loopback) Received data from srv03 Exiting after 20 seconds. To change this timeout, use the --timeout command line option. Command validate-multicast executed successfully.srv03.internal.dev同時為srv02.internal.dev ，還執行以下srv03.internal.dev ：
payara@srv03$ asadmin validate-multicast Will use port 2048 Will use address 228.9.3.1 Will use bind interface null Will use wait period 2,000 (in milliseconds)Listening for data... Sending message with content "srv03" every 2,000 milliseconds Received data from srv03 (loopback) Received data from srv02 Exiting after 20 seconds. To change this timeout, use the --timeout command line option. Command validate-multicast executed successfully.在同一時間運行這兩個命令時，實例之間的通信應該成功。 在srv02機器上，您應該看到“從srv03接收到的數據”，在srv03機器上，您應該看到“從srv02接收到的數據”。 這驗證了用于HttpSession復制的節點實例之間使用的多播網絡通信是否正常運行。
就是這樣！ 現在，群集已完全配置，并且可以在多臺計算機上運行。 我確定您急于將應用程序部署到集群中。 因此，請深入了解如何為高可用性（HA），會話復制的環境配置WAR。
WAR配置
一旦配置了Payara集群并使其正常運行，大多數人認為部署到該集群的任何應用程序都將利用該集群的高可用性（HA）和會話復制。 不幸的是，這種情況并非如此。 您的應用程序必須針對集群進行開發和配置。 本節將概述：
注意所有這些配置都是必需的。 如果僅跳過1，則跨群集的會話復制將無法進行。
應用程序所需的第一件事是會話序列化。 接下來將簡要介紹這一點。
會話序列化
HttpSession序列化是一件簡單的事情，但是大多數開發團隊對此卻很少關注。 通常，應用程序服務器使用序列化在整個群集中復制會話。 如果HttpSession中的對象無法序列化，則會話復制將失敗。 因此，請確保放入HttpSession 所有對象都可以序列化。
會話序列化是關鍵配置。 如果跳過它，則跨群集的會話復制將無法進行。
注意在開發環境中，請使用javax.servlet.Filter運行您的應用程序，該程序嘗試序列化HttpSession所有對象。 如果您進行了適當的測試，則應該可以解決任何序列化問題。
現在HttpSession中的所有對象都可以序列化了，接下來要看的是web.xml配置。
web.xml <distributable />
Servlet 3.1規范的第157頁將web.xml的<distributable />元素定義為“ <distributable />表示此Web應用程序已適當編程，可以部署到分布式Servlet容器中。” 這意味著必須將<distributable />添加到web.xml以便Payara知道該應用程序將在集群中運行，并且應該這樣處理。 清單1顯示了一個示例。
清單1 –可分發
<?xml version="1.0" encoding="UTF-8"?> <web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"version="3.1"><display-name>clusterjsp</display-name><distributable/><servlet><display-name>HaJsp</display-name><servlet-name>HaJsp</servlet-name> <jsp-file>/HaJsp.jsp</jsp-file></servlet><servlet><display-name>ClearSession</display-name><servlet-name>ClearSession</servlet-name> <jsp-file>/ClearSession.jsp</jsp-file></servlet><session-config><session-timeout>30</session-timeout></session-config><welcome-file-list><welcome-file>HaJsp.jsp</welcome-file></welcome-file-list> </web-app><distributable />元素是關鍵配置。 如果丟失，則跨群集的會話復制將無法進行。
<distributable />元素是所有Java EE服務器所需的配置。 Payara也有一些自己的自定義配置。 接下來要看的是此服務器特定的配置。
glassfish-web.xml cookieDomain
glassfish-web.xml文件是Web應用程序特定于Payara的配置文件。 不同web.xml這是適用于所有的Java EE服務器， glassfish-web.xml僅適用于GlassFish的或似鯖水狼牙魚EE服務器。 這意味著，如果要部署到其他EE服務器，則可能需要找到該服務器的等效配置，也可能不需要。
對于Payara，必須更新glassfish-web.xml以添加cookieDomain屬性。 清單2顯示了正確設置cookieDomain值的標記層次結構。 如清單2所示，該值設置為.internal.dev （Hafner，2011年）。 您還記得嗎，這是您用于群集體系結構的域。
清單2 – cookieDomain
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE glassfish-web-app PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN" "http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd"> <glassfish-web-app error-url=""><session-config>**<cookie-properties><property name="cookieDomain" value=".internal.dev"/></cookie-properties>**</session-config> </glassfish-web-app>cookieDomain屬性配置很重要，因為它允許JSESSIONID cookie（用于跟蹤群集節點實例之間的用戶會話）在每個Web瀏覽器請求中傳遞給任何群集節點實例。 了解此處發生情況的最簡單方法是解釋缺少cookieDomain屬性配置時發生的情況。
注意這是即將發生的事情的預覽，但這沒關系。
假設缺少cookieDomain屬性配置。 然后，Web瀏覽器使用URL http://srv02.internal.dev:28080/ferris-clusterjsp向在一個群集節點實例上運行的應用程序發出請求。 當應用程序處理請求時，它將創建一個JSESSIONID cookie，并且該cookie的域值將（默認情況下）為用于訪問應用程序的主機名，在本例中為srv02.internal.dev 。 現在，另一個請求發送到URL http://srv03.internal.dev:28080/ferris-clusterjsp 。 它是集群的一個實例，因此您希望該實例找到已經創建的會話。 但這不會發生。 因為JSESSIONID Cookie是使用域值**srv02**.internal.dev創建的，所以不會發生，因此Web瀏覽器不會根據對http://**srv03**.internal.dev的請求發送此Cookie。因為cookie屬于srv02而不是srv03 。
現在假設如清單2所示配置cookieDomain屬性配置。現在會發生什么？ 嗯，Web瀏覽器使用URL http://srv02.internal.dev:28080/ferris-clusterjsp向在一個集群節點實例上運行的應用程序發出請求。 但是，這一次，當應用程序處理請求時，它將創建一個JSESSIONID cookie，并且該cookie的域值將是您在清單2中將其配置為.internal.dev 。 現在，另一個請求發送到URL http://srv03.internal.dev:28080/ferris-clusterjsp 。 Web瀏覽器將隨此請求一起發送JSESSIONID，因為cookie屬于.internal.dev并且該請求將發送到http://srv03**.internal.dev** 。
cookieDomain屬性是關鍵配置。 如果缺少該域，或者所使用的域與cookieDomain值不匹配，則跨群集的會話復制將無法進行。
恭喜你 您的Web應用程序已配置完畢，可以部署到集群中。 部署很容易完成，接下來您將要做。
戰爭部署
至此，您終于可以部署WAR了。 好吧，不完全是。 你有戰爭嗎？ 沒有？ 好吧，你很幸運。 clusterjsp應用程序在測試集群和會話復制中很受歡迎。 我在我的GitHub帳戶上擁有自己的clusterjsp分支，該分支已經配置并可以部署到此示例集群。 您可以在https://github.com/mjremijan/ferris-clusterjsp/releases下載我的clusterjsp分支。 在本節中，您將看到：
部署命令
首先，您必須從我的GitHub帳戶下載 ferris-clusterjsp-1.1.0.0.war 。 接下來，使用asadmin命令將其部署到集群。 在srv01.internal.dev上執行以下srv01.internal.dev ：
$ asadmin deploy --force true --precompilejsp=true --enabled=true --availabilityenabled=true --asyncreplication=true --target c1 --contextroot=ferris-clusterjsp --name=ferris-clusterjsp:1.1.0.0 ferris-clusterjsp-1.1.0.0.warApplication deployed with name ferris-clusterjsp:1.1.0.0. Command deploy executed successfully.–force true強制重新部署該Web應用程序，即使該Web應用程序已被部署。
–precompilejsp = true ferris-clusterjsp應用程序使用一些簡單的JSP文件，因此請在部署時對其進行預編譯。
–enabled = true允許在應用程序部署后對其進行訪問。
–availabilityenabled = true允許通過會話復制和鈍化實現高可用性。 該方法也適用于有狀態會話Bean，盡管通常不再使用它們了。
–asyncreplication = true與處理用戶請求的線程相比，在單獨的異步線程中跨群集執行會話復制。
–target c1將應用程序部署到群集c1
–contextroot = ferris-clusterjsp將應用程序的上下文根設置為ferris-clusterjsp 。 這也可以在glassfish-web.xml定義。
–name = ferris-clusterjsp：1.1.0.0設置應用程序在Payara管理控制臺中的顯示名稱。 通常，最好在顯示名稱中包含版本號。
ferris-clusterjsp–1.1.0.0.war要部署的WAR文件的名稱。
現在已經部署了WAR，接下來要做的是驗證應用程序是否已成功部署并在所有群集節點實例上運行。
部署驗證
當您執行上面的asadmin deploy命令時，短時間后，您應該會看到“命令部署成功執行”消息。 如果是這樣，那就太好了！ 該應用程序已成功部署到群集。 要驗證它是否已成功部署，請在srv01.internal.dev上執行以下srv01.internal.dev ：
$ asadmin list-applications --long true --type web c1NAME TYPE STATUS ferris-clusterjsp:1.1.0.0 <web> enabled Command list-applications executed successfully.此asadmin命令要求Payara在群集c1上列出類型為web的所有應用程序。 應該有1個結果，即ferris-clusterjsp：1.1.0.0應用程序，并且其狀態應為enabled 。 為了確保一切正常，請通過在srv01.internal.dev上執行以下操作來srv01.internal.dev節點實例的狀態。
$ asadmin list-instances c1srv02-instance-01 running srv02-instance-02 running srv03-instance-01 running srv03-instance-02 running此asadmin命令告訴您c1集群中有4個實例，并且所有4個實例都在運行。 ferris-clusterjsp應用程序已在集群上成功運行。 接下來要做的就是測試！
WAR會話復制測試
現在是時候查看集群中的會話復制是否正在運行。 這樣做并不困難，但是，您將需要離開命令行世界，現在開始使用瀏覽器。 要測試會話復制是否正常工作，您需要：
鏈接到每個實例
您需要做的第一件事是找到URL，以訪問每個集群節點實例上的ferris-clusterjsp應用程序。 這是您的操作方式。 ferris-clusterjsp應用程序在4個群集節點實例上運行，并且每個實例都有自己的URL。 請按照以下步驟獲取鏈接列表：
單擊“ 應用程序”樹節點后，您將看到列出的ferris-clusterjsp：1.1.0.0應用程序。 圖2顯示在表的Action列中有一個名為Launch的超鏈接。 點擊它！
圖2 –
圖2 –啟動鏈接
單擊啟動鏈接后，將出現一個新的瀏覽器窗口，其中包含指向群集中應用程序的所有鏈接。 圖3顯示了8個鏈接。 可以通過HTTP或HTTPS訪問4個群集節點實例中的每一個。
圖3 –所有鏈接
圖3 –所有鏈接現在，您已經了解了所有鏈接，可以直接在4個實例中的每個實例上訪問ferris-clusterjsp應用程序。 這將允許您測試會話復制是否正常。 如果您的第一個請求是實例srv02-instance–01 ，那么您將能夠在其他3個實例上查看您的會話。 希望它會起作用！
測試復制
要測試會話復制是否正常工作，您需要做的就是在一個群集節點實例上訪問應用程序，記下會話ID值，然后在另一個節點實例上訪問該應用程序，然后查看會話是否已復制。 首先從srv02-instance–01開始 。 打開Web瀏覽器，然后瀏覽至http://srv02.internal.dev:28080/ferris-clusterjsp 。 該應用程序將顯示有關群集節點實例和您的會話的信息。 您的瀏覽器將類似于圖4a。
圖4a – srv02-instance-01上的ferris-custerjsp
圖4a – srv02-instance-01上的ferris-custerjsp圖4a突出顯示了您需要確認會話復制正常工作的一些信息。 首先，Web瀏覽器URL為http://srv02.internal.dev:28080/ferris-clusterjsp并且URL的主機名與頁面上的“ 從服務器提供服務”信息匹配。 此外，頁面還會顯示為您創建的會話ID –在本例中為7ec99da15ef5c79d7c4bc3149d6b 。
現在，您在應用程序上有一個會話，并且，如果一切正常，則應在整個集群中復制該會話。 要測試這一點，唯一要做的就是選擇另一個群集節點實例，看看是否獲得相同的會話。 選擇srv03-instance–02進行下一步測試。 該群集節點實例不僅位于完全不同的物理計算機上，而且還將協議從HTTP切換到HTTPS。 打開Web瀏覽器并瀏覽到https://srv03.internal.dev:28182/ferris-clusterjsp 。 圖4b顯示了應該發生的情況。
圖4b – srv03-instance-02上的ferris-custerjsp
圖4b – srv03-instance-02上的ferris-custerjsp圖4b顯示了結果，它們看起來非常好！ 突出顯示，您可以看到從HTTP到HTTPS的切換（您的Web瀏覽器還應該強制您接受證書）。 Web瀏覽器URL為https://srv03.internal.dev:28182/ferris-clusterjsp的主機名與頁面上的“ 從服務器提供服務”信息匹配。 但最重要的是，您將獲得相同的會話ID –在本例中為7ec99da15ef5c79d7c4bc3149d6b 。
現在，您可以享受一些樂趣，并進行更多的復制測試。 使用該頁面添加一些會話屬性數據，并查看它是否在集群中復制。 您首先使用哪個群集節點實例都沒有關系。 選一個。 然后轉到頁面的Enter session attribute data：部分，并添加會話數據，如圖5所示。
圖5 –添加會話屬性數據
圖5 –添加會話屬性數據單擊添加會話數據按鈕。 圖6顯示頁面將刷新，并且已添加會話屬性數據。
圖6 –添加的會話屬性數據
圖6 –添加的會話屬性數據添加會話屬性數據后，轉到其他瀏覽器并刷新頁面。 您會看到數據已被復制。 圖7并排顯示了具有相同的復制會話屬性數據的Web瀏覽器。
圖7 –瀏覽器并排使用相同的數據
圖7 –瀏覽器并排使用相同的數據恭喜你！ 您現在擁有了一個功能齊全的多VM會話復制群集。 但是仍然缺少一些東西：高可用性（HA）。 對于高可用性，您將需要一個負載均衡器。 因此，接下來要看的是負載均衡器配置。
負載均衡器配置
現在，您有一個很棒的多虛擬機，會話復制集群，但它是無用的，因為它尚不可訪問。 您具有訪問每個單獨的群集節點實例的鏈接，但是擁有1個實例的URL不會給您帶來高可用性（HA）。 現在，您需要的是一個負載平衡器，它可以將請求發送到通用URL（例如http://srv.internal.dev然后將請求代理到集群中的任何活動實例。 And, thanks to successfully setting up session replication across the cluster, it doesn't matter which instance the load balancer proxies your request to because your session data will be the same across the cluster. For this post, you are going to use NGINX as the the load balancer. This section will look at:
NGINX Installation
Installing NGINX is simple. You should be able to use apt-get to do this. Execute the following command on srv01.internal.dev . Remember in the architecture diagram for the zone, srv01.internal.dev is the machine in the zone which will run the load balancer.
$ apt-get install nginx而已。 NGINX is now installed. To get it working with your cluster node instances you will need to do a little configuration, which is what you will do next.
NGINX Configuration
This NGINX configuration is very simple. There are 2 things you need to do. The first is you need to setup an upstream configuration that contains the host names and port numbers of all the cluster node instances. The second is to update the location to proxy requests to the upstream .
upsteam First, look at the upstream configuration. Assuming you installed NGINX on srv01.internal.dev , open the /etc/nginx/nginx.conf file for editing. Edit the file and add an upstream configuration as shown in the following example. The upstream configuration goes inside of the http configuration.
http { upstream cluster_c1 {server srv02.internal.dev:28080;server srv02.internal.dev:28081;server srv03.internal.dev:28080;server srv03.internal.dev:28081;} }Restart NGINX to pick up the changes.
$ /etc/init.d/nginx restartlocation Next, look at the location configuration. Assuming you installed NGINX on srv01.internal.dev , open the /etc/nginx/sites-available/default file for editing. Edit the file and update the location configuration to MATCH the following example. The location configuration goes inside of the server configuration.
server { listen 80;server_name localhost;upstream cluster_c1 {location / {root html;index index.html index.htm;proxy_connect_timeout 10;proxy_send_timeout 15;proxy_read_timeout 20;proxy_pass http://cluster_c1;} }Restart NGINX to pick up the changes.
$ /etc/init.d/nginx restartNGINX Testing
By default, NGINX is configured to listen on port 80. You saw this in the previous section when you did the location configuration. If both NGINX and the Payara are up and running, here's the easiest way to test.
Because NGINX is configured as a proxy in front of Payara, the browser will show the Payara-is-now-running page as in Figure 8.
Figure 8 – Payara with localhost proxied through NGINX
Figure 8 – Payara with localhost proxied through NGINX而已。 NGINX is now configured and working. That means you have the High Availability (HA) piece of the architecture ready to test. You can do that next.
WAR High Availablity (HA) Testing
You're in the home stretch now. Here are all the pieces of the architecture so far:
Now it's time to see if all the pieces work together. For these final tests, you need to have a web browser capable of sending requests through the NGINX load balancer. Remember 2 very important things:
The easiest way to do this is to edit your testing machine's hosts file and add a host to test the cluster. Assume the test hostname will be srv.internal.dev . Then add the following to your testing machine's hosts file:
$ cat /etc/hosts 127.0.0.1 localhost 10.0.2.16 srv01.internal.dev srv01 10.0.2.17 srv02.internal.dev srv02 10.0.2.18 srv03.internal.dev srv03 10.0.2.16 srv.internal.devThe first test you should do is to repeat the simple NGINX test. Only this time use the hostname you just saved in the hosts file. Perform the test by doing the following:
Because NGINX is configured as a proxy in front of Payara, the browser will show the Payara-is-now-running page as in Figure 9. The difference this time is the URL uses the hostname saved in the hosts file.
Figure 9 – Payara with srv.internal.dev proxied through NGINX
Figure 9 – Payara with srv.internal.dev proxied through NGINXNow here comes the final test to make sure everything is working. Open a web browse to the ferris-clusterjsp application and see what happens. Perform the test by doing the following:
If everything goes OK, you will see the HA JSP Sample page handled by one of the cluster node instances. Figure 10 shows that srv03-instance-01 handled the first request.
Figure 10 – Payara with ferris-clusterjsp proxied through NGINX
Now the exciting part. Keep testing! Keep reloading the page. As seen in Figure 11, you will see the Served From Server instance: and Executed Server IP Address: change as the NGINX load balancer proxies requests to different cluster node instances, but the Session ID will remain the same. 涼！
Figure 11 – Payara with ferris-clusterjsp proxied through NGINX Figure 11 – Payara with ferris-clusterjsp proxied through NGINX
Now for an even more fun test. High Availability (HA) means if a cluster node instance goes down the application still keeps running and your users are not impacted. 試試吧！ Shut down one of the cluster node instances and see what happens. Execute the following command on srv01.internal.dev :
bash $ asadmin stop-instance srv03-instance-01
This will stop the 1 instance of the cluster. Now go back to your browser and start reloading the page. While you are reloading, watch the Served From Server instance: value. Because srv03-instance-01 is now shut down, you'll notice this instance will be skipped as the load balancer round-robins through the cluster instances. One instance of your cluster is stopped, but your application is still working fine. If you want to start the instance again, Execute the following command on srv01.internal.dev :
$ asadmin start-instance srv03-instance-01This will restart the instance. Now go back to your browser and start reloading the page again. While you are reloading, watch the Served From Server instance: value. You'll eventually notice srv03-instance-01 will come back! :)
摘要
My goal for this post was to consolidate in one place the instructions to create a high availability (HA), session replicated, multi-machined Payara/GlassFish cluster. Hopefully I accomplished that goal by giving instructions for the following:
I hope you have found this post useful. And also please note the title of this post says “(almost)” for a good reason: this is not the only way to create a high availability (HA), session replicated, multi-machined Payara/GlassFish cluster. But it is A way.
參考資料
Java Servlet 3.1 Specification (2013, May 28). Java Servlet 3.1 Specification for Evaluation [PDF]. Retrieved from http://download.oracle.com/otndocs/jcp/servlet-3_1-fr-eval-spec/index.html
Hafner, S. (2011, May 12). Glassfish 3.1 – Clustering Tutorial Part2 (sessions) [Web log post]. Retrieved from https://javadude.wordpress.com/2011/05/12/glassfish-3-1-%E2%80%93-clustering-tutorial-part2-sessions/ .
Hafner, S. (2011, April 25). Glassfish 3.1 – Clustering Tutorial [Web log post]. Retrieved from https://javadude.wordpress.com/2011/04/25/glassfish-3-1-clustering-tutorial/
Mason, R. (2013, September 03). Load Balancing Apache Tomcat with Nginx [Web log post]. Retrieved from https://dzone.com/articles/load-balancing-apache-tomcat
Fasoli, U. (2013, August 17). Glassfish Cluster SSH – Tutorial : How to create and configure a glassfish cluster with SSH (Part 2) [Web log post]. Retrieved from http://ufasoli.blogspot.com/2013/08/
Fasoli, U. (2013, July 17). Glassfish asadmin without password [Web log post]. Retrieved from http://ufasoli.blogspot.fr/2013/07/glassfish-asadmin-without-password.html
Oracle GlassFish Server 3.1 Section 1: asadmin Utility Subcommands. （nd）。 Retrieved from https://docs.oracle.com/cd/E18930_01/html/821-2433/gentextid-110.html#scrolltoc
Camarero, RM (2012, January 21). clusterjsp.war [WAR]. Retrieved from http://blogs.nologin.es/rickyepoderi/uploads/SimplebutFullGlassfishHAUsingDebian/clusterjsp.war
Croft, M. (2016, June 30). Creating a Simple Cluster with Payara Server [Web log post]. Retrieved from http://blog.payara.fish/creating-a-simple-cluster-with-payara-server
Administering GlassFish Server Clusters. (nd) Retrieved from https://docs.oracle.com/cd/E26576_01/doc.312/e24934/clusters.htm#GSHAG00005
Administering GlassFish Server Nodes. （nd）。 Retrieved from https://docs.oracle.com/cd/E26576_01/doc.312/e24934/nodes.htm#GSHAG00004
Administering GlassFish Server Instances. （nd）。 Retrieved from https://docs.oracle.com/cd/E26576_01/doc.312/e24934/instances.htm#GSHAG00006
翻譯自: https://www.javacodegeeks.com/2017/06/high-availability-ha-session-replicated-multi-vm-payara-cluster.html
payara 創建 集群
總結
以上是生活随笔為你收集整理的payara 创建 集群_高可用性（HA），会话复制，多VM Payara群集的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 过度收集用户数据会损害用户隐私大数据未能
- 下一篇： envoy重试_具有Envoy代理的微服