Table of Contents
ネットワーク管理者は、しばしばファイルと印刷サービスの可用性について関心を持っている。 ネットワークユーザーは、きわめて重要な、責任ある仕事を遂行するのに依存するサービスに 対して、厳しい態度をとりがちである。
コンピュータールームにある以下の標語が、スタッフに自らの責任を思い起こさせるのであった。 それは以下のようなものであった:
すべての人間は過ちを犯すものである。大小を問わず、我々は絶えず過ちを犯している。 機会も同様に故障するものである。コンピューターは人によって管理される機械であり、 故障の結果は悲惨なものとなりうる。管理者の責任は、故障に対処し、故障を予測し、 人知の及ぶ限り、かつ経済的に合理的な範囲でその可能性を抹消することに他ならない。 あなたの行動は、問題の一部となるか、それとも解決の一部となるか。
もしも、計画的、生産的な方法で障害に対処するのであれば、まず最初に問題を理解する 必要がある。それがこの章の目的である。
以下の議論には障害に対抗するためにネットワーク基盤をどのように展開すべきかについての ポイントとなる情報も含まれている。ただし、ここでの目的は、高可用性に関する長大な論文を 発表することではない。そのため、高可用性を提供するソリューションの具体的な実例は提示 していない。Samba を含む CIFS/SMB 技術を展開する際に適用するための、高可用性に関する 最新の知識とノウハウの紹介を主眼に置いた詳細なドキュメントの作成に誰か が挑戦してくれることを期待して、ここでの記述は概論に留める判断を行っている。
以下の要約は、2003年4月に、ドイツのゲッティンンゲンで行われた、SambaXP 2003 カンファレンスで、Jeremy Allisonによって行われた発表の一部である。 素材となる情報は、幾つか追加されているが、それらを以下の構成に まとめあげたのは、Jeremy ならではである。
すべてのクラスターリング技術は以下の1つあるいはそれ以上を達成することを目的としている:
コンピューターの能力を最大限使えること。
より高速なプロトコル実行を行うこと。
無停止サービスを提供すること。
単一障害点を避けること。
資源を最も効果的に使うこと。
クラスター化されたファイルサーバーは理想的に以下の属性を有している:
すべてのクライアントはどのサーバーにも透過的に接続できる。
サーバーが故障するとクライアントは透過的に他のサーバーに再接続できる。
すべてのサーバーは、同じファイル群を提供する。
すべてのファイルの変更は、すべてのサーバーで直接行われるように見える。
分散ファイルシステムが必要。
より多くのサーバーやディスクを追加することで、無限に拡張できる。
簡単に言うと、問題は状態(state)にある。
1つの名前と1つのIPアドレスを持つ単一のサーバーのように、ファイルサーバーの クラスターを見せるためにすることは可能で、クライアントから受信した TCPデータストリームはフロントエンドの仮想サーバーによって処理される必要が ある。このサーバーはSMBプロトコルレイヤレベルで、入力したパケットを分割し、 次に、クラスター中の異なったサーバーにSMBパケットを中継する。
印刷とユーザー検索要求を扱うためには、すべてのIPC$接続とRPC呼び出しを1台の サーバーに振り分けるしかない。RPC印刷ハンドルは、異なったIPC$ セッションで共有される。これをクラスターを構成するサーバー間で 分割するのは難しい!
概念的に、他のすべてのサーバーはファイルサービスのみ提供する。これは 集中させるよりも簡単な問題である。
SMBリクエストを分割する事は、SMBステート情報を知っていることが要求され、そのすべては フロントエンドの仮想サーバーによって保持されねばならない。 これは解決するのには複雑で難しい問題である。
Windows XPとその後継は、その意味を変更し、そのため、ステート情報 (vuid,tid,fid)は操作が成功するために一致しなければならない。これは、 以前よりも物事を単純にし、前へ進むためのよい一歩である。
SMBリクエストは、それに対応するサーバーにvuidによって送られる。 このソリューションを作り出すコードは現在存在しない。この問題は、 Samba中で、Windows 2000ターミナルサーバーからの複数のリクエストからの リクエストを正しく処理する問題と、概念的に似ている。
UNIXとLinux用に、たくさんの分散ファイルシステムがある。
SMB文法を認識することを、ずっと心にとめている間は、我々のクラスターの バックエンドに多くが適用できる(共有モード、ロックとoplock問題は特に)。 一般的な自由に使える分散ファイルシステムには以下がある: Many could be adopted to backend our cluster, so long as awareness of SMB semantics is kept in mind (share modes, locking, and oplock issues in particular). Common free distributed file systems include:
NFS
AFS
OpenGFS
Lustre
サーバープール(クラスター)は、もしもすべてのSMB文法がそのプール内で実行出来るならば、 任意の分散ファイルシステムを使える。
クラスター化されたサーバーが純粋なSMBサービスを提供するとき、oplockの 処理は、バックエンドのファイルシステムプールに渡す必要性はなく、 サーバープール内で完結してもよい。
他方、サーバープールがNFSや他のファイルサービスをも提供する場合、 SMBサービスと相互運用できるように、oplockを認識する実装は基本である。 これは、現在有意義な挑戦である。これの相互運用性の提供に失敗すると、 Microsoft Windows クライアントのユーザーによってはっきりと気がつく 明確な性能の低下をもたらす。
最後に、すべてのステート情報は、サーバープール間で共有されるべきである。
ほとんどのバックエンドファイルシステムは、POSIXファイルシステムを サポートしている。これは、SMB文法をファイルシステム中で使うことを 困難にしている。POSIXのロック機構は、SMBのロック機構とは異なる 属性と文法である。
サーバープール中のすべてのsmbdプロセスはごく短時間に
通信しなければならない。このため、Sambaが使う現在の
tdbファイル構造はネットワーク間で使うのには
適していない。クラスター化されたsmbdは何らかの、
他のものを使う必要がある。
サーバープール内の高速サーバー間通信は、完全に機能するシステムのために あらかじめ必要な機能である。これを可能にするものは以下のものがある:
商用の共有メモリバス(例:MyrinetまたはSCI [scalable coherent interface])。 これはとても価格が高い。
ギガビットイーサネット(現在簡単に使える)。
生のイーサネットフレーミング(TCPとUDPのオーバーヘッドをバイパス)。
これらの機能を有効化する効果の有無を計るパフォーマンス指標はまだ確立していない。
Sambaは、透過的なフィルオーバークラスターが出来るように、高速サーバー間接続システムで 動くように、明確に修正する必要がある。
影響を受けると思われるSamba内の特定の機能は以下の通り:
フェイルオーバーサーバーにエクスポートされたファイルシステム内で異なった機能を 扱えるようにすることは、分散ロッキングプロトコルを要求する問題をなくす。
もしも、ペアの中で1つのサーバーのみアクティブである場合、高速サーバー間通信の必要性は 無くなる。この場合、新しいものを開発する代わりに、既存の高可用性ソリューションが 使える。これはかなりのコストがかかる単純なソリューションである。 そのコストとは、より複雑なファイル名空間を管理する必要があるということである。 単一のファイルシステムではないため、管理者はすべてのサービスがどこに配置されて いるかを覚えておかなければならない。複雑さは、扱うのが容易ではない。
仮想サーバーは、バックエンドサーバーに要求をリダイレクトする ため、引き続き必要である。バックエンドファイル空間の完全性は管理者の責任である。
フェイルオーバーサーバーはリソースのフェイルオーバーを扱うために通信する必要がある。 これは高可用性サービスでは基本である。専用のハートビートを使うことは、 フェイルオーバープロセスで、ある種の自立性を導入する、一般的な技術である。 これは、しばしは専用のリンク(LANまたはシリアル通信)上で行われる。
多くのフェイルオーバーソリューション(Red HatクラスターマネージャとMicrosoft Wolfpack のような)はフェイルオーバー通信のためにファイバチャネルディスクストレージアレイ をSCSIで共有して使える。Sambaに対するRed Hat高可用性ソリューションについての 情報は、 www.redhat.com で得られる。
Linux高可用性プロジェクトは、高可用性Sambaファイルサーバーソリューションを構築 したいならば、考慮するに値するリソースである。 www.linux-ha.org/にある ホームページを見てほしい。
フロントエンドサーバーの複雑性は、すべてのネットワーククライアントに対して、 サービスの継続性を同時に提供する間、バックエンドの障害をうまく扱わなければ ならないという理由で、高可用性に対する挑戦の余地がある。