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/にある ホームページを見てほしい。
フロントエンドサーバの複雑性は、すべてのネットワーククライアントに対して、 サービスの継続性を同時に提供する間、バックエンドの障害をうまく扱わなければ ならないという理由で、高可用性に対する挑戦の余地がある。