Chapter 32. 高可用性
Prev | Part III. 詳細な設定方法 | Next

## Chapter 32. 高可用性

### John H. Terpstra

Samba Team

`<jht@samba.org>`

### Jeremy Allison

Samba Team

`<jra@samba.org>`

## 機能と利便性

ネットワーク管理者は、しばしばファイルと印刷サービスの可用性について関心を持っている。ネットワークユーザは、きわめて重要な、責任ある仕事を遂行するのに依存するサービスに対して、厳しい態度をとりがちである。

コンピュータルームにある以下の標語が、スタッフに自らの責任を思い起こさせるのであった。それは以下のようなものであった:

> すべての人間は過ちを犯すものである。大小を問わず、我々は絶えず過ちを犯している。機会も同様に故障するものである。コンピュータは人によって管理される機械であり、故障の結果は悲惨なものとなりうる。管理者の責任は、故障に対処し、故障を予測し、人知の及ぶ限り、かつ経済的に合理的な範囲でその可能性を抹消することに他ならない。あなたの行動は、問題の一部となるか、それとも解決の一部となるか。

もしも、計画的、生産的な方法で障害に対処するのであれば、まず最初に問題を理解する必要がある。それがこの章の目的である。

以下の議論には障害に対抗するためにネットワーク基盤をどのように展開すべきかについてのポイントとなる情報も含まれている。ただし、ここでの目的は、高可用性に関する長大な論文を発表することではない。そのため、高可用性を提供するソリューションの具体的な実例は提示していない。Samba を含む CIFS/SMB 技術を展開する際に適用するための、高可用性に関する最新の知識とノウハウの紹介を主眼に置いた詳細なドキュメントの作成に誰かが挑戦してくれることを期待して、ここでの記述は概論に留める判断を行っている。

## 技術的な議論

以下の要約は、2003年4月に、ドイツのゲッティンンゲンで行われた、SambaXP 2003カンファレンスで、Jeremy Allisonによって行われた発表の一部である。素材となる情報は、幾つか追加されているが、それらを以下の構成にまとめあげたのは、Jeremy ならではである。

### 最終目的

すべてのクラスタリング技術は以下の1つあるいはそれ以上を達成することを目的としている:

- コンピュータの能力を最大限使えること。

- より高速なプロトコル実行を行うこと。

- 無停止サービスを提供すること。

- 単一障害点を避けること。

- 資源を最も効果的に使うこと。

クラスタ化されたファイルサーバは理想的に以下の属性を有している:

- すべてのクライアントはどのサーバにも透過的に接続できる。

- サーバが故障するとクライアントは透過的に他のサーバに再接続できる。

- すべてのサーバは、同じファイル群を提供する。

- すべてのファイルの変更は、すべてのサーバで直接行われるように見える。

  - 分散ファイルシステムが必要。

- より多くのサーバやディスクを追加することで、無限に拡張できる。

### これがなぜ難しいか?

簡単に言うと、問題は状態(state)にある。

- すべてのTCP/IP接続はステート情報に依存する。

  TCP接続はパケットシーケンス番号を持っている。このシーケンス 番号は、シームレスなTCPフェールオーバーを引き起こすために、 クラスタ中で、すべてのマシン上で動的に更新される必要がある。

- CIFS/SMB(Windowsネットワークプロトコル)はTCP接続を使用している。

  これは、基本的な設計の見地から、フェイルオーバーは真剣に考慮 されていない事を意味する。

  - すべての現在のSMBクラスタはフェールオーバーソリューション である。これらは再接続するクライアントに 頼っている。これは、サーバのフェールオーバーを提供するが、 クライアントはサーバの故障のために情報を失う可能性がある。

- サーバはクライアント接続に関するステート情報を保存する。

  - CIFS/SMBには多くのステートがある。

  - すべてのファイルのオープンは、共有モードを チェックするために他のオープンしているファイルと比較する。

#### 最先端の状況

1つの名前と1つのIPアドレスを持つ単一のサーバのように、ファイルサーバの クラスタを見せるためにすることは可能で、クライアントから受信した TCPデータストリームはフロントエンドの仮想サーバによって処理される必要が ある。このサーバはSMBプロトコルレイヤレベルで、入力したパケットを分割し、 次に、クラスタ中の異なったサーバにSMBパケットを中継する。

印刷とユーザ検索要求を扱うためには、すべてのIPC$接続とRPC呼び出しを1台の サーバに振り分けるしかない。RPC印刷ハンドルは、異なったIPC$ セッションで共有される。これをクラスタを構成するサーバ間で 分割するのは難しい!

概念的に、他のすべてのサーバはファイルサービスのみ提供する。これは 集中させるよりも簡単な問題である。

#### SMBリクエストの分割

SMBリクエストを分割する事は、SMBステート情報を知っていることが要求され、そのすべては フロントエンドの仮想サーバによって保持されねばならない。 これは解決するのには複雑で難しい問題である。

Windows XPとその後継は、その意味を変更し、そのため、ステート情報 (vuid,tid,fid)は操作が成功するために一致しなければならない。これは、 以前よりも物事を単純にし、前へ進むためのよい一歩である。

SMBリクエストは、それに対応するサーバにvuidによって送られる。 このソリューションを作り出すコードは現在存在しない。この問題は、 Samba中で、Windows 2000ターミナルサーバからの複数のリクエストからの リクエストを正しく処理する問題と、概念的に似ている。

直接クライアントにサーバプールを提示することで開始するという 1つの可能性がある。これは、分割ステップを省略できる。

#### 分散ファイルシステムの試み

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は、透過的なフィルオーバクラスタが出来るように、高速サーバ間接続システムで 動くように、明確に修正する必要がある。

影響を受けると思われるSamba内の特定の機能は以下の通り:

- データベースのロック、oplockの通知と共有モードデータベース。

- 何をもって「障害」とみなすかを定義する必要がある。Sambaは Windowsと同様に動作する。oplockが失敗を通知すると、ファイル オープン要求は許可されるが、これはクラスタ環境では潜在的な 危険性がある。サーバ間プールの障害という意味は、どのように 位置づけるべきか、またこうした機能をどのように実装すべきか。

- これはポイントツーポイントロックマネージャを使って実装すべきか、 あるいは、マルチキャスト手法を使って行うべきだろうか?

### 簡単なソリューション

フェイルオーバサーバにエクスポートされたファイルシステム内で異なった機能を 扱えるようにすることは、分散ロッキングプロトコルを要求する問題をなくす。

もしも、ペアの中で1つのサーバのみアクティブである場合、高速サーバ間通信の必要性は 無くなる。この場合、新しいものを開発する代わりに、既存の高可用性ソリューションが 使える。これはかなりのコストがかかる単純なソリューションである。 そのコストとは、より複雑なファイル名空間を管理する必要があるということである。 単一のファイルシステムではないため、管理者はすべてのサービスがどこに配置されて いるかを覚えておかなければならない。複雑さは、扱うのが容易ではない。

仮想サーバは、バックエンドサーバに要求をリダイレクトする ため、引き続き必要である。バックエンドファイル空間の完全性は管理者の責任である。

### 高可用性サーバ製品

フェイルオーバサーバはリソースのフェイルオーバを扱うために通信する必要がある。 これは高可用性サービスでは基本である。専用のハートビートを使うことは、 フェイルオーバプロセスで、ある種の自立性を導入する、一般的な技術である。 これは、しばしは専用のリンク(LANまたはシリアル通信)上で行われる。

多くのフェイルオーバソリューション(Red HatクラスタマネージャとMicrosoft Wolfpack のような)はフェイルオーバ通信のためにファイバチャネルディスクストレージアレイ をSCSIで共有して使える。Sambaに対するRed Hat高可用性ソリューションについての 情報は、 www.redhat.com で得られる。

Linux高可用性プロジェクトは、高可用性Sambaファイルサーバソリューションを構築 したいならば、考慮するに値するリソースである。 www.linux-ha.org/にある ホームページを見てほしい。

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

### MS-DFS: 貧者のクラスター

MS-DFSリンクは異なったバックエンドサーバにクライアントをリダイレクトするのに 使われる。これはMicrosoftによってすでに導入された何かで、ネットワーククライアントに 複雑性を増やしてしまう。MS-DFSは単純な、ファイルレベルでさえ動作する、継続的な ファイルシステム名前空間という幻影を作成する。

とりわけ、管理の複雑さを犠牲にすると、分散システム(仮のクラスタ)は既存のSambaの 機能を使うことで作成できる。

### 結論

- 透過的なSMBクラスタは作るのが難しい!

- クライアントフェイルオーバは現在出来る最も良いものである。

- 実用的で管理が楽な高可用性透過的クラスタソリューションを可能にする前には、 たくさんの作業が必要である。

- MS-DFSは単一の透過的クラスタという幻想を作るのことができる。

Prev | Up | Next
Chapter 31. バックアップテクニック | Home | Chapter 33. 大きなディレクトリの取扱い