2014_2_25_JBossClustering概念

2014_2_25_JBossClustering

开会，ppt，jboss clustering

##1 deep learning：
###1.1 Farm服务，是不是简单的文件同步？
A：应该是。
 due to an implementation weakness, the farm deployment service only works for 1) **archives located in the farm/ directory of the first node** to join the cluster or 2) hot-deployed archives. 
 
###1.2 集群的客户端拦截器架构解释：
将转发做在拦截器端？
JBoss应用服务器提供的remote服务，需要客户端obtain一个remote proxy object。proxy对象由服务器生成，并且实现了服务的业务接口。客户端通过proxy对象进行local方法调用，proxy自动路由调用到服务器，由服务器端的服务对象来完成调用。由proxy对象决定如何找到合适的server，marshal调用参数，unmarshal返回结果，并将结果返回用户。在cluster环境下，服务器生成的proxy对象，包含一个拦截器，拦截器知道如何将调用路由给集群中的多个节点。

##2 Questions：

###2.1 apache+mod_jk是基于的HTTP协议，而jboss EJB应用是基于RMI的。
那么前端使用HTTP协议的Router，能否支持RMI？以及how?
首先，session EJB提供远程方法调用RMI，They are clustered based on the ***client-side interceptor architecture***. 基于的是客户端拦截器架构。

通过apache+mod_jk,那么用jsp的话？rmi访问好像可以.

> <%  Context ctx = new InitialContext();  %>

负载均衡可以做到？就目前jsp测试的结果看，没有做负载均衡或者说负载均衡做的相当不好，根据mok_log看到localhost 0.03.
当一直使用的node2挂掉后，localhost 0.24,然后又降到0.05.这些值代表啥？
请求将转发给node1。
再次重启节点node2，结果请求还是都转发给node1了。

对于html请求，也开始出现了一边倒,apache出问题了？
重启apache，还是严重不均衡，

但是java-client却做了负载均衡？

为什么呢，转发都可以了。。。

更奇怪的是，如果我给InitialContext里面陪置ip的话，反而会进行负载的转发？

> Properties properties=new Properties();
			properties.setProperty("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");
			properties.setProperty("java.naming.provider.url", "localhost:1099");
			Context ctx=new InitialContext(properties);

  一个jboss作为公共访问口，进行LB，其余JBoss节点组成集群：在一个jboss内构建对外的web客户端来访问其它多个集群后的ejb服务的系统是完全可行的，这样要求这个对外web客户端的jboss不能参与ejb的集群。这种方式看上去有点类似于apache+mod_jk+jboss的http集群，但本质上是不太一样的。

  AJP是Apache提供的完成与其它服务器通讯的一种协议。在Apache中通过mod_proxy_ajp模块发送AJP数据,另外一端的服务器需要实现AJP协议，能够接受mod_proxy_ajp模块发送的AJP协议数据，在接受到AJP协议数据后做适当处理，并能够将处理结果以AJP协议方式发送回给mod_proxy_ajp模块。
  mod_jk是apache与tomcat通信的模块。是个插件。Mod_JK是Apache的一個模塊，其通過AJP協議實現Apache與Tomcat之間的通訊，而Tomcat默認監聽AJP連接器的8009端口來接受AJP的連接請求；一般這些請求來自前端的Apache服務器。由於Mod_JK已經被設計成Apache的一個模塊，因此可以通過一些相對簡單的配置就能達到Apache和Tomcat之間通訊的目的；同樣包含負載均衡。
  
  這裏主要觀察session的stickiness是如何被實現的；已經Apache服務器如何瞭解到關於Session ID相關的信息。
實際上對於負載均衡來說，如果上面的例子中你配置了兩個Tomcat，那麼關閉sticky_session的情況下，每個Tomcat服務器將輪流收到請求。

其實在試驗的時候發現session ID是Tomcat服務器分配創建的，Apache服務器只是用來管理其與Tomcat服務器之間的關係；當然Apache服務器需要檢查每次請求中的Session ID。這個ID是由Tomcat分配的；Tomcat對於每個第一次請求的動態頁面都會生成JSESSIONID；而對於靜態頁面是不會生成JESSIONID的。

具體運行過程：

1.  Apache服務器接收到來自client的請求，檢查HTTP請求是否包含SESSIONID

2.  如果不包含，採用負載均衡算法選擇一個Tomcat服務器

3.  Apache服務器將這個client請求轉發到選定Tomcat服務器的8009端口，數據包的格式是AJP協議

4.  Tomcat解析AJP協議，生成SESSION_ID並且取得響應，將結果發送給Apache服務器，這個是通過之前的8009連接過來的鏈接發送回去的。

5.  Apache服務器解析AJP包，並得到SESSION_ID信息，並將其與對應的服務器（和會話）關聯起來。

6.  Apache將SESSION ID轉發給client

7.  Client將Session ID保存到Cookie中用於下次使用。
  
**AJP（Apache JServer Protocol）**
  AJPv13協議是面向包的。WEB服務器和Servlet容器通過TCP連接來交互；爲了節省SOCKET創建的昂貴代價，WEB服務器會嘗試維護一個永久TCP連接到servlet容器，並且在多個請求和響應週期過程會重用連接。
  一旦一個連接被分配給特定的請求，在請求處理週期結束之前這個連接不能被重用；換句話說，請求不是連接多工的。這樣編碼比較簡單。
  一旦連接被分配給特定的請求，基本請求信息（HTTP頭）以壓縮的個性（通常字符串會編碼爲整數）；如果有請求實體，會隨後立即發送。
  這個時候，servlet容器已經準備好了處理請求並發送西面的信息回WEB服務器：

1.       SEND_HEADERS：發回瀏覽器的響應頭
2.       SEND_BODY_CHUNK：將實體發送給瀏覽器
3.       GET_BODY_CHUNK：獲取更多的請求數據，這些數據沒有被發送。
4.       END_RESPONSE：表示請求處理週期結束。

WEB服務器發送給Servlet容器的請求包括：

1.       轉發請求開始
2.       關閉
3.       Ping
4.       CPing

###2.2 JGroups作为JBoss Clustering的核心技术，
与PaceMaker的关系？比较？

PaceMaker也是用于HA（高可用）

###2.3 相比JBoss Cluster，CloudFoundry的灵活性，使用范围，可用性，node节点健康状态的检查


----------


###2.4 Cloud与Cluster的关系与比较：
some computing paradigms have promised to deliver this **utility computing** vision and these include cluster computing, 
Grid computing, and more recently Cloud computing

云指的是unlimited space and processing power。Cloud Computing refers to both the applications delivered as services over the Internet and the hardware and
systems software in the datacenters that provide those services. "A Cloud is a type of parallel and distributed system consisting of a collection of inter-connected and virtualized computers that are dynamically provisioned and presented as one or more unified computing resource(s) based on service-level agreements established through negotiation between the service provider 
and consumers.

集群指的是a set of logically connected machines/device. A cluster is a type of parallel and distributed system, which consists of a collection of inter-connected  stand-alone computers working together as a single integrated computing resource.”

 1. Cluster也是水平扩展多个服务器，但是是在本地局域网的一组服务器。
cloud可以更广。
 2. Cluster是紧耦合的，而cloud是松耦合的，
 3. cluster中的节点一般使用相似的硬件。而cloud中的机器可能硬件配置相差很大。
 

Clusters are configurable in Active-Active or Active-Passive ways. 
主-主模式和主-被模式

----------


5 NOSql服务器，建立一个阵列，存储< key,value>

TODO:
session的缓存？
stateful session的缓存？


----------

1.       Apache是世界排名第一的Web服務器；在Apache基金會裏其永遠被第一支持。而開源的Apache Tomcat也非常關注，由於開源，用戶最支持。

2.       Apache支持**靜態頁面**，Tomcat支持**動態頁面**（servlet,JSP）；一般在使用Apache + Tomcat的配置下，Apache都是實現對JSP的轉發，交給Tomcat來處理。Apache可以支持PHP，但如果要支持JAVA，就需要Tomcat來處理。

3.       Apache是Web服務器，Tomcat是應用（Java）服務器，它只是一個servlet容器，是Apache的擴展，但可以獨立於Apache運行；如果以獨立方式運行，功能與Apache等效，但對靜態頁面的處理不太理想。

----------


負載均衡技術主要有：
 
1. 基於DNS的負載均衡
通過DNS服務中的隨機名字解析來實現負載均衡，在DNS伺服器中，可以為多個不同的地址配置同一個名字，而最終查詢這個名字的
 
客戶機將在解析這個名字時得到其中一個地址。因此，對於同一個名字，不同的客戶機會得到不同的地址，他們也就訪問不同地址
 
上的Web伺服器，從而達到負載均衡的目的。
 
 2. 反向代理負載均衡 （如Apache+JK2+Tomcat這種組合）
使用代理伺服器可以將請求轉發給內部的Web伺服器，讓代理伺服器將請求均勻地轉發給多台內部Web伺服器之一上，從而達到負載
 
均衡的目的。這種代理方式與普通的代理方式有所不同，標準代理方式是客戶使用代理訪問多個外部Web伺服器，而這種代理方式
 
是多個客戶使用它訪問內部Web伺服器，因此也被稱為反向代理模式。
 
3. 基於NAT（Network Address Translation）的負載均衡技術 （如Linux Virtual Server，簡稱LVS）網路地址轉換為在內部地址和外部地址之間進行轉換，以便具備內部地址的計算機能訪問外部網路，而當外部網路中的計算機訪問
 
地址轉換網關擁有的某一外部地址時，地址轉換網關能將其轉發到一個映射的內部地址上。因此如果地址轉換網關能將每個連接均勻轉換為不同的內部伺服器地址，此後外部網路中的計算機就各自與自己轉換得到的地址上伺服器進行通信，從而達到負載分擔的目的。