[sugj-tech:7323] TOSHARG-HighAvailability.xmlのわからない点(05)
gwmaster
ribbon @ ns.ribbon.or.jp
2010年 1月 29日 (金) 19:14:41 JST
英文が付いているところが、訳が微妙なところです。
<indexterm><primary>Myrinet</primary></indexterm>
<indexterm><primary>scalable coherent interface</primary><see>SCI</see></indexterm>
<listitem><para>
商用の共有メモリバス(例:MyrinetまたはSCI [scalable coherent interface])。
これはとても価格が高い。
</para></listitem>
<listitem><para>
ギガビットイーサネット(現在簡単に使える)。
</para></listitem>
<listitem><para>
生のイーサネットフレーミング(TCPとUDPのオーバヘッドをバイパス)。
</para></listitem>
</itemizedlist>
<para>
これを有効にし、効果的にするための性能要求のための計測を識別することは
まだしていない。
We have yet to identify metrics for performance demands to enable this to happen
effectively.
Sambaは、透過的なフィルオーバクラスタが出来るように、高速サーバ間接続システムで
動くように、明確に修正する必要がある。
</para>
<para>
影響を受けると思われるSamba内の特定の機能は以下の通り:
</para>
<itemizedlist>
<listitem><para>
データベースのロック、oplockの通知と共有モードデータベース。
</para></listitem>
<listitem><para>
<indexterm><primary>failure semantics</primary></indexterm>
<indexterm><primary>oplock messages</primary></indexterm>
障害の意味を定義する必要がある。SambaはWindowsと同じように
振る舞う。oplockが失敗を通知したとき、ファイルオープン
要求は許可されるが、これはクラスタ環境では潜在的に危険である。
そのため、どのようにサーバ間プールの障害の意味が機能するかと、
どのようにそのような機能を実装したらよいだろうか?
Failure semantics need to be defined. Samba behaves the same way as Windows.
When oplock messages fail, a file open request is allowed, but this is
potentially dangerous in a clustered environment. So how should interserver
pool failure semantics function, and how should such functionality be implemented?
</para></listitem>
<listitem><para>
これはポイントツーポイントロックマネージャを使って実装すべきか、
あるいは、マルチキャスト手法を使って行うべきだろうか?
</para></listitem>
oota
sugj-tech メーリングリストの案内