ホーム
製品
Red Hat JBoss Enterprise Application Platform
5
管理設定ガイド
第18章概要とクイックスタート

第18章概要とクイックスタート

クラスタリングにより、アプリケーションクライアントに単一のビューを提供しつつ、1 つのアプリケーションを複数の並列サーバー (クラスターノード) で実行することができるようになります。負荷は複数のサーバーに分散されるため、1 つまたは複数のサーバーに障害が発生した場合でも、障害が発生しなかったクラスターノードからアプリケーションにアクセスすることができます。クラスターにノードを追加するだけでパフォーマンスを向上させることができるクラスタリングはスケーラブルな企業向けアプリケーションに欠かせません。また、クラスタリングインフラストラクチャーが高可用性を実現するのに必要な冗長性をサポートするため、クラスタリングは可用性の高い企業アプリケーションを実現するためにも重要です。

production サーバープロファイルの一部として、 JBoss Enterprise Application Platform にはそのまま使用できるクラスタリングサポートが含まれています。production サーバープロファイルには次のサポートが含まれています。

スケーラブルでフォールトトレラントな JNDI 実装 (HA-JNDI)。
次を含む Web 層クラスタリング。
- ステートレプリケーションによる Web セッションステートの高可用性。
- ハードウェアロードバランサーやソフトウェアロードバランサーとの統合が可能( mod_jk や JK ベースのソフトウェアロードバランサーとの特殊な統合など)。
- クラスター全体のシングルサインオンサポート。
ステートフル Bean およびステートレス Bean に対する、EJB3 とEJB2 両方の EJB セッション Bean クラスタリング
JPA/Hibernate エンティティに対する分散キャッシュ。
ノード上で Bean に変更があった時にクラスター全体でキャッシュエントリを無効化し、クラスター全体におけるローカル EJB2 エンティティキャッシュの整合性を維持するフレームワーク。
分散 JMS キューと JBoss Messaging によるトピック。
クラスターの複数のノード上でサービスかアプリケーションをデプロイし、1 つのノード上のみでアクティブにすることを HA シングルトンと呼びます。
Farm サービスにて、デプロイされたコンテンツの同期化をクラスターのすべてのノード上で維持します。

本 クラスタリングガイド は、 JBoss Enterprise Application Platform におけるクラスタリング機能の使用方法を深く理解することを目的としています。最初に、 JBoss Enterprise Application Platform のクラスタリングをお試しいただくため、基本的な「クイックスタート」の手順を紹介し、 JBoss Enterprise Application Platform クラスタリングの仕組みを理解していただくため、基礎的な情報を提供します。次に、クラスター機能を使用して JEE サービスをクラスターする方法について詳しく説明します。最後に、 JGroups と JBoss Cache の上級設定、 JBoss Enterprise Application Platform クラスタリングの基礎となる技術について詳しく説明します。

18.1. クイックスタートガイド
リンクのコピー

本項の目的は、 JBoss Enterprise Application Platform のクラスタリングを使用するために最低必要な情報を提供することです。本項に記載されている内容の多くは、本項以降で詳しく説明されています。

18.1.1. 最初の準備
リンクのコピー

JBoss Enterprise Application Platform クラスターがサーバーのセットとして動作するよう準備するには、次の手順に従います。

JBoss Enterprise Application Platform をすべてのサーバーにインストールします。 JBoss のダウンロードを各サーバー上のファイルシステムに展開するのが最も簡単な方法です。
複数の JBoss Enterprise Application Platform インスタンスを単一のサーバーで実行したい場合は、完全な JBoss ディストリビューションをファイルシステムの複数の場所にインストールするか、production サーバープロファイルのコピーを作成します。例えば、JBoss ディストリビューションのルートが /var/jboss に展開された場合、次を行います。
```
cd /var/jboss/server
cp -r production node1
cp -r production node2
```
```
$ cd /var/jboss/server
$ cp -r production node1
$ cp -r production node2
```
Copy to Clipboard Toggle word wrap
各ノードに対して、ソケットをバインドするアドレスを決定します。 クラスター化の有無に関係なく、 JBoss を起動する際に、ソケットがトラフィックをリッスンするアドレスを JBoss に伝える必要があります (デフォルトは localhost で、安全ですがクラスター内ではあまり実用的ではありません)。そのため、アドレスを決める必要があります。
マルチキャストが動作しているか確認します。 デフォルトでは、 JBoss Enterprise Application Platform はほとんどのクラスタ内での通信で UDP マルチキャストを使用します。各サーバーのネットワーク設定がマルチキャストをサポートし、サーバー間のスイッチやルーターに対してマルチキャストサポートが有効になっているようにしてください。 1 つのサーバー用で複数のノードを実行したい場合は、サーバーのルーティングテーブルにマルチキャストルートが含まれているようにしてください。マルチキャストが動作しているかを確認する JGroups の分析ツールの使用方法など、詳細は http://www.jgroups.org のJGroups ドキュメントを参照してください。
注記
JBoss Enterprise Application Platform のクラスタリングは UDP マルチキャストの使用を必要としません。クラスター内での通信で TCP ユニキャストを使用するよう再設定することもできます。
ノード毎に一意の整数 "ServerPeerID" を決定します。 これは JBoss Messaging のクラスタリングに必要で、JBoss Messaging を実行しない場合は必要ありません (サーバープロファイルの deploy ディレクトリから JBM を削除する場合など)。JBM を実行する場合、クラスターの各ノードには"ServerPeerID" と呼ばれる固有の整数 ID が必要になります。
重要
簡単な「1, 2, 3, ..., x」のようなネーミングスキームで構いませんが、値は 0 から 1023 の範囲でなければなりません。この範囲外の値になると、ServerPeer 起動サービスで java.lang.IllegalArgumentExceptionが発生します。
「JBoss Enterprise Application Platform クラスターの起動」にて、ServerPeerID の使用方法について説明します。

上記が必須の手順となりますが、クラスターをネットワークで実行されている他の JBoss Enterprise Application Platform クラスターから適切に分離するため、次の 2 つのオプション手順が推奨されます。

クラスターに対して固有の名前を選択します。 JBoss Enterprise Application Platform クラスターのデフォルトの名前は「DefaultPartition」です。ご自分の環境の各クラスターに対して異なる名前を付けてください (「QAPartition」や「BobsDevPartition」など)。名前に「Partition」を使用する必要はありませんが、慣例的に使用されます。クラスターの周囲で送信されるすべてのメッセージに名前が含まれるため、パフォーマンスを考慮して短い名前を付けるようにしてください。選択した名前の使用方法については次の項で取り上げます。
クラスターに対して固有のマルチキャストアドレスを選択します。 デフォルトでは、 JBoss Enterprise Application Platform はほとんどのクラスタ内の通信に UDP マルチキャストを使用します。実行する各クラスターに対して異なるマルチキャストアドレスを選択してください。一般的に、マルチキャストアドレスには 239.255.x.y の形式を使用するのがよいでしょう。マルチキャストアドレスの割り当てについては、 http://www.29west.com/docs/THPM/multicast-address-assignment.html を参照してください。選択したアドレスの使用方法については、次の項で説明します。

クラスターの分離についての詳細は、「JGroups チャネルの分離」を参照してください。

18.1.2. JBoss Enterprise Application Platform クラスターの起動
リンクのコピー

JBoss サーバークラスターを開始する一番簡単な方法は、各インスタンスに -c production コマンドラインオプションを使用して同じローカルネットワーク上で複数の JBoss インスタンスを開始することです。これらのサーバーインスタンスは相互に検出を行い、自動的に 1 つのクラスターを形成します。

ここで、いくつかの異なるシナリオを見てみましょう。すべてのシナリオで 2 ノードクラスターを 1 つ作成し、最初のノードは 1、 2 つ目のノードは 2 とします。クラスターの名前を「DocsPartition」とし、 239.255.100.100 をマルチキャストアドレスとして使用するようにします。シナリオは例の提示を目的としています。例として最も単純であるため 2 ノードのクラスターを使用しますが、 2 ノードがサイズ的に最適であるとは限りません。

シナリオ 1: 個別のマシン上のノード
このシナリオは実稼働環境では最も一般的なシナリオです。マシン名は「node1」と「node2」で、 node1 の IP アドレスは 192.168.0.101、 node2 の IP アドレスは 192.168.0.102 とします。 node1 の ServerPeerID は 1 、 node2 の ServerPeerID は 2 とし、各マシンの /var/jboss に JBoss がインストールされているとします。
node1 で JBoss を開始します。
```
cd /var/jboss/bin
./run.sh -c production -g DocsPartition -u 239.255.100.100 \
    -b 192.168.0.101 -Djboss.messaging.ServerPeerID=1
```
```
$ cd /var/jboss/bin
$ ./run.sh -c production -g DocsPartition -u 239.255.100.100 \
    -b 192.168.0.101 -Djboss.messaging.ServerPeerID=1
```
Copy to Clipboard Toggle word wrap
node2 でも同様ですが、 -b の値と ServerPeerID の値が異なります。
```
cd /var/jboss/bin
./run.sh -c production -g DocsPartition -u 239.255.100.100 \
    -b 192.168.0.102 -Djboss.messaging.ServerPeerID=2
```
```
$ cd /var/jboss/bin
$ ./run.sh -c production -g DocsPartition -u 239.255.100.100 \
    -b 192.168.0.102 -Djboss.messaging.ServerPeerID=2
```
Copy to Clipboard Toggle word wrap
-c スイッチは、クラスタリングサポートが含まれる production 設定の使用を指示します。 -g スイッチは、クラスター名を設定します。 -u スイッチはクラスター内での通信で使用されるマルチキャストアドレスを設定します。 -b スイッチはソケットがバインドされるアドレスを設定します。 -D スイッチは、 JBoss Messaging が固有の ID を取得するシステムプロパティ jboss.messaging.ServerPeerID を設定します。
シナリオ 2: 単一のマルチホームサーバー上の 2 ノード
同じマシンで複数のノードを実行することは開発環境では一般的で、実稼働環境でもシナリオ 1 を併用して使用されます (すべてのノードを単一マシン上の実稼働クラスタで実行することは、マシン自体が単一障害点となるため通常推奨されません)。このシナリオでは、マシンがマルチホーム化されています (複数の IP アドレスを持っている状態)。これにより、各JBoss インスタンスを異なるアドレスにバインドできるため、ノードがソケットを開ける際の競合を防ぐことができます。
単一のマシンにアドレスとして 192.168.0.101 と 192.168.0.102 が割り当てられ、シナリオ 1 と同様に 2 つの JBoss インスタンスが同じアドレスと ServerPeerIDs を使用するとします。シナリオ 1 との違いは、 Enterprise Application Platform インスタンスが独自のワークエリアを持つようにすることです。そのため、 production 設定を使用せずに、前項で production よりコピーした node1 設定と node2 設定を使用するようにします。
最初のインスタンスを起動するため、コンソールウインドウを開いて次を実行します。
```
cd /var/jboss/bin
./run.sh -c node1 -g DocsPartition -u 239.255.100.100 \
    -b 192.168.0.101 -Djboss.messaging.ServerPeerID=1
```
```
$ cd /var/jboss/bin
$ ./run.sh -c node1 -g DocsPartition -u 239.255.100.100 \
    -b 192.168.0.101 -Djboss.messaging.ServerPeerID=1
```
Copy to Clipboard Toggle word wrap
2 つ目のインスタンスも同様ですが、 -b 値、 -c 値、 ServerPeerID が異なります。
```
cd /var/jboss/bin
./run.sh -c node2 -g DocsPartition -u 239.255.100.100 \
    -b 192.168.0.102 -Djboss.messaging.ServerPeerID=2
```
```
$ cd /var/jboss/bin
$ ./run.sh -c node2 -g DocsPartition -u 239.255.100.100 \
    -b 192.168.0.102 -Djboss.messaging.ServerPeerID=2
```
Copy to Clipboard Toggle word wrap
シナリオ 3: マルチホーム化されていない単一サーバー上の 2 ノード
シナリオ 2 と似ていますが、マシンの IP アドレスは 1 つのみになります。 2 つのプロセスはソケットと同じアドレスやポートにバインドできないため、 2 つのインスタンスに異なるポートを使用するよう JBoss に伝える必要があります。これには、 jboss.service.binding.set システムプロパティを設定して ServiceBindingManager サービスを設定します。
最初のインスタンスを起動するため、コンソールウインドウを開いて次を実行します。
```
cd /var/jboss/bin
./run.sh -c node1 -g DocsPartition -u 239.255.100.100 \
    -b 192.168.0.101 -Djboss.messaging.ServerPeerID=1 \
    -Djboss.service.binding.set=ports-default
```
```
$ cd /var/jboss/bin
$ ./run.sh -c node1 -g DocsPartition -u 239.255.100.100 \
    -b 192.168.0.101 -Djboss.messaging.ServerPeerID=1 \
    -Djboss.service.binding.set=ports-default
```
Copy to Clipboard Toggle word wrap
2 つ目のインスタンスには次を実行します。
```
cd /var/jboss/bin
./run.sh -c node2 -g DocsPartition -u 239.255.100.100 \
    -b 192.168.0.101 -Djboss.messaging.ServerPeerID=2 \
    -Djboss.service.binding.set=ports-01
```
```
$ cd /var/jboss/bin
$ ./run.sh -c node2 -g DocsPartition -u 239.255.100.100 \
    -b 192.168.0.101 -Djboss.messaging.ServerPeerID=2 \
    -Djboss.service.binding.set=ports-01
```
Copy to Clipboard Toggle word wrap
これは、最初のノード上にある ServiceBindingManager に標準のポートセット (1099 番ポート上の JNDI など) を使用するよう指示します。 2 つ目のノードは、標準のポート番号から 100 を引いた番号 (1199 番ポート上の JNDI など) を持つ各ポートのデフォルトである ports-01 を使用します。 ServiceBindingManager 設定の全体については、 conf/bindingservice.beans/META-INF/bindings-jboss-beans.xml ファイルを参照してください。
この設定は異なるポートを使用し、管理が複雑になるため、実稼働環境への使用は推奨されません。クラスタリングを使用したいのにワークステーションをマルチホーム化できない開発環境では一般的なシナリオとなります。
注記
技術的に、 ports-default はデフォルト値であるため、 node1 のコマンドラインに-Djboss.service.binding.set=ports-default を含める必要はありませんが、慣れていないユーザーはすべてのサーバーで統一されたコマンドライン引数を使用した方が簡単でしょう。

これで終了です。 JBoss Enterprise Application Platform サーバーのクラスターを開始し、実行することができるようになります。

18.1.3. Web アプリケーションクラスタリングのクイックスタート
リンクのコピー

JBoss Enterprise Application Platform は、クラスターにある 1 つ以上のノードに各ユーザーの HttpSession ステートのバックアップコピーが保存されるクラスタ化された Web セッションをサポートします。セッションを処理する 1 次ノードに障害が発生あるいは停止した場合、クラスターの別のノードがバックアップコピーにアクセスし、セッションの後続要求を処理することができます。Web 層クラスタリングの詳細は『HTTP コネクター負荷分散ガイド』を参照してください。

Web 層クラスタリングには 2 つの側面があります。

外部ロードバランサーの設定。Web アプリケーションは、 JBoss Enterprise Application Platform インスタンスのクラスター全体で HTTP 要求を負荷分散するため、外部ロードバランサーを必要とします (その理由については、「外部ロードバランサーアーキテクチャー」を参照)。 JBoss Enterprise Application Platform 自体は HTTP ロードバランサーとして機能しないため、ハードウェアロードバランサーかソフトウェアロードバランサーを設定する必要があります。選択できるロードバランサーは多く存在するため、ロードバランサーの設定方法については本クイックスタートの範囲外となります。よく使用される mod_jk ソフトウェアロードバランサーの設定についての詳細は、『HTTPコネクター負荷分散ガイド』を参照してください。
クラスタリングに対する Web アプリケーションの設定。これには、特定の Web アプリケーションに対する希望のクラスタリング動作を JBoss に伝える必要があります。それには、空の distributable 要素をアプリケーションの web.xml ファイルに追加します。
```
<?xml version="1.0"?> 
<web-app  xmlns="http://java.sun.com/xml/ns/javaee"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
          xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
                              http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" 
          version="2.5">
          
    <distributable/>
    
</web-app>
```
```
<?xml version="1.0"?> 
<web-app  xmlns="http://java.sun.com/xml/ns/javaee"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
          xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
                              http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" 
          version="2.5">
          
    <distributable/>
    
</web-app>
```
Copy to Clipboard Toggle word wrap
上記を実行すれば、ほとんどのアプリケーションでデフォルトの JBoss Enterprise Application Platform のWeb セッションクラスタリング動作を実行できるはずです。詳細設定オプションについては、『HTTP コネクター負荷分散ガイド』を参照してください。

18.1.4. EJB セッション Bean クラスタリングのクイックスタート
リンクのコピー

JBoss Enterprise Application Platform は、クラスター全体で Bean の要求が分散されるクラスターされた EJB セッション Bean をサポートします。ステートフル Bean については、 Bean ステートのバックアップコピーは 1 つ以上のクラスターノードで維持されるため、特定のセッションを処理しているノードに障害が発生あるいは停止した場合に高可用性を提供できます。 EJB2 Bean と EJB3 Bean 両方のクラスタリングがサポートされます。

EJB3 セッション Bean の場合、 org.jboss.ejb3.annotation.Clustered アノテーションをステートフル Bean またはステートレス Bean の Bean クラスに追加します。

@javax.ejb.Stateless
@org.jboss.ejb3.annotation.Clustered
public class MyBean implements MySessionInt {
   
   public void test() {
      // Do something cool
   }
}

@javax.ejb.Stateless
@org.jboss.ejb3.annotation.Clustered
public class MyBean implements MySessionInt {
   
   public void test() {
      // Do something cool
   }
}

Copy to Clipboard

Toggle word wrap

EJB2 セッション Bean や、アノテーションでなく XML 設定を使用したい EJB3 Bean の場合、 JBoss 固有の配備記述子である jboss.xml の Bean のセクションに、 clustered 要素を追加します。

<jboss>    
    <enterprise-beans>      
        <session>        
            <ejb-name>example.StatelessSession</ejb-name>        
            <jndi-name>example.StatelessSession</jndi-name>        
            <clustered>true</clustered>
        </session>
    </enterprise-beans>
</jboss>

<jboss>    
    <enterprise-beans>      
        <session>        
            <ejb-name>example.StatelessSession</ejb-name>        
            <jndi-name>example.StatelessSession</jndi-name>        
            <clustered>true</clustered>
        </session>
    </enterprise-beans>
</jboss>

Copy to Clipboard

Toggle word wrap

詳細の設定オプションについては、22章クラスター化されたセッション EJB を参照してください。

18.1.5. エンティティクラスタリングのクイックスタート
リンクのコピー

JBoss Enterprise Application Platform 5 のクラスタリングで大幅に改善された機能の 1 つが、 Hibernate 3.3 で導入された 2 次エンティティキャッシングに対して新しい Hibernate/JBoss Cache 統合を使用することです。 JPA/Hibernate コンテキストでは、 2 次キャッシュは、トランザクションの範囲外で保持されたコンテンツを持つキャッシュを参照します。データベースの読み取り回数を減らすと、 2 次キャッシュのパフォーマンスが改良されることがあります。常に 2 次キャッシュを有効にしてアプリケーションの負荷をテストし、無効にしてから特定のアプリケーションに対して有益であるか確認するようにしてください。

複数の JBoss Enterprise Application Platform インスタンスを使用して JPA/Hibernate アプリケーションを実行し、 2 次キャッシュを使用する場合、クラスター対応のキャッシュを使用しなければなりせん。クラスター対応のキャッシュを使用しないと、サーバー B 上のアクティビティがエンティティを更新した後でもサーバー A 上のキャッシュは古いデータを保持することになります。

JBoss Enterprise Application Platform は、 JBoss Cache を基にしたクラスター対応の 2 次レベルを提供します。 JBoss Enterprise Application Platform の標準の Hibernate ベース JPA プロバイダーが JBoss Cache での 2 次キャッシングを有効にするには、 persistence.xml を次のように設定します。

<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
   http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
   version="1.0"> 
   <persistence-unit name="somename" transaction-type="JTA">
      <jta-data-source>java:/SomeDS</jta-data-source>
      <properties>
         <property name="hibernate.cache.use_second_level_cache" value="true"/>
         <property name="hibernate.cache.region.factory_class" 
                   value="org.hibernate.cache.jbc2.JndiMultiplexedJBossCacheRegionFactory"/>
         <property name="hibernate.cache.region.jbc2.cachefactory" value="java:CacheManager"/>
         <!-- Other configuration options ... -->
      </properties>
   </persistence-unit>
</persistence>

<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
   http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
   version="1.0"> 
   <persistence-unit name="somename" transaction-type="JTA">
      <jta-data-source>java:/SomeDS</jta-data-source>
      <properties>
         <property name="hibernate.cache.use_second_level_cache" value="true"/>
         <property name="hibernate.cache.region.factory_class" 
                   value="org.hibernate.cache.jbc2.JndiMultiplexedJBossCacheRegionFactory"/>
         <property name="hibernate.cache.region.jbc2.cachefactory" value="java:CacheManager"/>
         <!-- Other configuration options ... -->
      </properties>
   </persistence-unit>
</persistence>

Copy to Clipboard

Toggle word wrap

これにより、 Hibernate が JBoss Cache ベースの 2 次キャッシュを使用するよう指示しますが、キャッシュするエンティティは指定されていません。キャッシュするエンティティを指示するには、 org.hibernate.annotations.Cache アノテーションをエンティティクラスに追加します。

package org.example.entities;
 
import java.io.Serializable;
import javax.persistence.Entity;
import org.hibernate.annotations.Cache;
import org.hibernate.annotations.CacheConcurrencyStrategy;
 
@Entity
@Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL)
public class Account implements Serializable {

package org.example.entities;
 
import java.io.Serializable;
import javax.persistence.Entity;
import org.hibernate.annotations.Cache;
import org.hibernate.annotations.CacheConcurrencyStrategy;
 
@Entity
@Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL)
public class Account implements Serializable {

Copy to Clipboard

Toggle word wrap

詳細設定オプションや、 JPA でない Hibernate アプリケーションを同様に設定する方法については、 23章クラスター化した Entity EJB を参照してください。

注記

クラスタリングは JPA/Hibernate の 2 次キャッシュのオーバーヘッドを大幅に増加させます。そのため、 2 次キャッシングがクラスター化されていないアプリケーションに有益であってもクラスター化されたアプリケーションにも有益であるとは限りません。クラスター化された 2 次キャッシングが総合的に有益である場合、頻繁に変更されるエンティティタイプはクラスター化されていない場合に有益でもクラスター化されていると有益でないこともあります。常にアプリケーションの負荷をテストするようにしてください。

トップに戻る

第18章概要とクイックスタート

18.1. クイックスタートガイド
リンクのコピー

18.1.1. 最初の準備
リンクのコピー

18.1.2. JBoss Enterprise Application Platform クラスターの起動
リンクのコピー

18.1.3. Web アプリケーションクラスタリングのクイックスタート
リンクのコピー

18.1.4. EJB セッション Bean クラスタリングのクイックスタート
リンクのコピー

18.1.5. エンティティクラスタリングのクイックスタート
リンクのコピー

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

第18章 概要とクイックスタート

18.1. クイックスタートガイドリンクのコピーリンクがクリップボードにコピーされました!

18.1.1. 最初の準備リンクのコピーリンクがクリップボードにコピーされました!

18.1.2. JBoss Enterprise Application Platform クラスターの起動リンクのコピーリンクがクリップボードにコピーされました!

18.1.3. Web アプリケーションクラスタリングのクイックスタートリンクのコピーリンクがクリップボードにコピーされました!

18.1.4. EJB セッション Bean クラスタリングのクイックスタートリンクのコピーリンクがクリップボードにコピーされました!

18.1.5. エンティティクラスタリングのクイックスタートリンクのコピーリンクがクリップボードにコピーされました!

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

第18章概要とクイックスタート

18.1. クイックスタートガイド
リンクのコピー

18.1.1. 最初の準備
リンクのコピー

18.1.2. JBoss Enterprise Application Platform クラスターの起動
リンクのコピー

18.1.3. Web アプリケーションクラスタリングのクイックスタート
リンクのコピー

18.1.4. EJB セッション Bean クラスタリングのクイックスタート
リンクのコピー

18.1.5. エンティティクラスタリングのクイックスタート
リンクのコピー