[jboss-cvs] JBossAS SVN: r73100 - projects/docs/trunk/AS_4/Server_Configuration_Guide/ja-JP.

Wed May 7 03:29:00 EDT 2008

Author: khashida at redhat.com
Date: 2008-05-07 03:29:00 -0400 (Wed, 07 May 2008)
New Revision: 73100

Modified:
   projects/docs/trunk/AS_4/Server_Configuration_Guide/ja-JP/Clustering_Guide_HTTP.po
Log:
all done

Modified: projects/docs/trunk/AS_4/Server_Configuration_Guide/ja-JP/Clustering_Guide_HTTP.po
===================================================================

--- projects/docs/trunk/AS_4/Server_Configuration_Guide/ja-JP/Clustering_Guide_HTTP.po	2008-05-07 06:40:48 UTC (rev 73099)
+++ projects/docs/trunk/AS_4/Server_Configuration_Guide/ja-JP/Clustering_Guide_HTTP.po	2008-05-07 07:29:00 UTC (rev 73100)
@@ -11,7 +11,7 @@
 "Project-Id-Version: Clustering_Guide_HTTP\n"
 "Report-Msgid-Bugs-To: http://bugs.kde.org\n"
 "POT-Creation-Date: 2007-12-10 22:33+0000\n"
-"PO-Revision-Date: 2008-05-07 14:24+1000\n"
+"PO-Revision-Date: 2008-05-07 17:27+1000\n"
 "Last-Translator: Kiyoto Hashida <khashida at redhat.com>\n"
 "Language-Team: Japanese <jp at li.org>\n"
 "MIME-Version: 1.0\n"
@@ -2228,6 +2228,15 @@
 "and stopped in tandem with the Barrier. When the BarrierController is "
 "undeployed the Barrier is destroyed too."
 msgstr ""
+"これが機能する方法は、BarrierController が jboss.ha:service=HASingletonDeployer MBean と共に "
+"導入されて、そこから出る JMX 通知をリッスンすることです。BarrierController は比較的に簡単な "
+"Mbean で、これはシステム内のいずれの JMX 通知でも受信するように購読ができます。BarrierController は "
+"受信した通知を使用して Barrier と言う名の動的に作成された Mbean のライフサイクルを制御します。 "
+"Barrier は BarrierController が導入された時に具体化され、登録されて、CREATE 状態にされます。 "
+"その後は、BarrierController が 適合する JMX 通知を受け取った時に Barrier の開始と停止をします。 "
+"このようにして、他のサービスは通常 &lt;depends&gt; タグを使用して Barrier MBean に依存するだけで、 "
+"それらのサービスは Barrier と並行して開始と停止をします。BarrierController の導入が解除されると、 "
+"Barrier も破壊されます。"
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:437
@@ -2237,6 +2246,9 @@
 "can use farming to distribute the service, while content in deploy-"
 "hasingleton must be copied manually on all nodes."
 msgstr ""
+"deploy-hasingleton のコンテンツが全てのノード上でコピーされる必要があるのに対し、我々は"
+"farming を使用してサービスを分配することができます。この意味でこの方法が deploy-hasingleton アプローチへの "
+"代替を提供します。"
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:440
@@ -2248,6 +2260,9 @@
 "that will only deploy (instantiate/create/start) the contents of the deploy-"
 "hasingleton directory on one of the nodes."
 msgstr ""
+"その一方、barrier-依存 のサービスは全てのノード上で 具体化/作成（いずれかの呼び起こされたcreate() メソッド） "
+"されますが、マスターノード上のみで開始されます。この点は、ノード群内の１つだけで deploy-hasingleton "
+"ディレクトリのコンテンツを導入（具体化/作成/開始）する deploy-hasingleton アプローチとは異なります。"
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:444
@@ -2271,6 +2286,11 @@
 "normal “undeploy” operation (like, for example, an <literal>EJBContainer</"
 "literal>) will not have the desired effect."
 msgstr ""
+"Barrier は 依存しているサービスの開始/停止を制御しますが、<literal>BarrierController</"
+"literal> が破壊/導入解除する時だけに発生する、それらの破壊はしません。そのため、 "
+"<literal>Barrier</literal> を使用して、その通常の「導入解除」操作 の一部として"
+"（例、<literal>EJBContainer</literal>）「破壊」する必要のあるサービスを制御することは "
+"期待する効果を出しません。"
 
 #. Tag: title
 #: Clustering_Guide_HTTP.xml:457
@@ -2287,6 +2307,9 @@
 "membership and correctly decide whether it is now the “master node”. How is "
 "this done?"
 msgstr ""
+"各種のクラスター化 singleton 管理の戦略は全て、クラスター内の各ノードが独立して "
+"クラスターのメンバーシップの変更に反応して、自身がマスターノードであるかどうかを "
+"正しく判定できると言う事実に依存します。それはどのようにして起こるのでしょうか？"
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:461
@@ -2302,6 +2325,13 @@
 "literal> mbean. Every member of the cluster will have the same view, with "
 "the members in the same order."
 msgstr ""
+"JBoss AS 4.2.0 以前は、この為の方法論は固定化しており簡単でした。クラスターの "
+"各メンバーには、HAPartition mbean が CurrentView と言う属性を維持しており、 "
+"それが基本的にクラスター内の現在メンバーの順番付き一覧だったのです。ノード群が "
+"クラスターに参加と退去をする度に、JGroups は、クラスターの各残存メンバーが更新した "
+"一覧表示を得ることを確実にしました。JMX コンソールに入り、<literal>jboss:service=DefaultPartition</"
+"literal> mbean の CurrentView 属性を見ることで現在の一覧表示を確認することができます。クラスター内の "
+"全てのメンバーが同じ順番に配置されたメンバーの同じ一覧表示を得ることができます。"
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:464
@@ -2313,6 +2343,10 @@
 "the cluster (although this is not always the case, and should not be assumed "
 "to be the case.)"
 msgstr ""
+"例として、４ノードのクラスターがあると想定しましょう。ノード A からノード D まで、 "
+"そして現在の一覧表示は {A, B, C, D} として表現できます。一般的に言うとこの一覧内の "
+"ノードの順番は、それらがクラスターに参加した順番を反映していると言えます "
+"（常にこのようになるとは言えません。これが定説とは言えません）。"
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:467
@@ -2326,6 +2360,12 @@
 "<literal>HAPartition</literal> service knows that the view with respect to "
 "the Foo service is {A, C, D} (no B)."
 msgstr ""
+"この例を更に進めて、Foo と呼ばれる１つの singleton サービス（<literal>HASingletonController</literal>）が "
+"あると想定しましょう。これが何かの理由でノード B 以外のクラスター全体に導入されているとします。 "
+"<literal>HAPartition</literal> サービスは、どのサービスがどこで、導入されているかに付いての登録の "
+"一覧表示をクラスター全域に関して維持しています。その為、クラスター内の全てのノードについて "
+"<literal>HAPartition</literal> サービスは、Foo サービスが {A, C, D} に対してある （B にはない）と "
+"言う見解を持っています。"
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:471
@@ -2340,6 +2380,13 @@
 "does this by checking if they are the first member of the view – if they "
 "are, they are the master; if not, they're not. Simple as that."
 msgstr ""
+"Foo サービスのクラスタートポロジーに変更がある時、<literal>HAPartition</literal> サービスは "
+"Foo 上にコールバックを呼び起こして、それに新規のトポロジーを通知します。そこで例として、 "
+"Foo が D 上で開始した時に、 A と C と D の全てで実行中の Foo サービスがコールバックを受けて "
+"新規の一覧表示が {A, C, D} であると伝えられます。このコールバックは各ノードに十分な情報を "
+"与えるため、それぞれが独立的にマスターであるかどうか判定できます。各ノード上の Foo サービスは "
+"その一覧表示の中で彼らが一番最初のメンバーかどうかをチェックすることでこれを実行します。 "
+"そのノードがそうである場合、それがマスターになり、そうでないとマスターではないと言うことになります。"
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:475
@@ -2351,4 +2398,9 @@
 "would remain the master – there's nothing magic about A that would cause it "
 "to become the master again just because it was before."
 msgstr ""
+"A が故障か、シャットダウンになった場合、C と D 上の Foo は、{C, D} となる Foo 用の "
+"新規一覧付きのコールバックを受け取ります。そうすると C がマスターになります。もし、 "
+"A が再開始すると、A と C と D は {C, D, A} となる Foo 用の新規一覧でコールバックされます。 "
+"C はマスターとして維持されます。・・・A が以前に存在したと言うだけの理由では A には再度 "
+"マスターになるようなマジックはありません。"
 


