SAMBAベースのフォールトトレラントファイルサービスの実装

この記事では、Sambaパッケージに基づくフォールトトレラントファイルサーバーの構成について説明します。 この資料を理解するには、Linux OS管理の一般的な理解と、Sambaの通常バージョンの経験が必要です。







Sambaは、CIFSプロトコルのセマンティクス（およびWindowsマシンからのアクセス）をPOSIXファイルシステムを使用する環境に提供するように設計されたCIFSサービスです。 Sambaの主な機能は、Windowsベースのクライアントが使用する豊富なセマンティクスを、より貧弱なPOSIXファイルシステムのセマンティクスに変換することです。







このような変換を実行するために、Sambaはセマンティクス変換で使用される追加情報を含む多くの内部メタデータデータベースを使用します。



特に、追加のパラメーターは、異なるクライアントから同じファイルを同時に開くことなどを担当します。

この情報は、POSIXでファイルを直接開く前に必ず処理されます。

したがって、WindowsクライアントからPOSIXファイルシステムへの透過的なアクセスが提供されます。



Sambaのフォールトトレランスは、3つのポイントに基づいています。

• Sambaメタデータデータベースの回復
• クラスタファイルシステムベースのユーザーファイルの可用性
• ネットワーク障害保護メカニズム。障害が発生したノードから動作中のノードにIPアドレスを転送します。

この記事では、フォールトトレラントCIFSサービスを作成するメカニズムについてのみ説明します。 実装の前提条件は、ファイルを保存するために直接使用される並列クラスタファイルシステムの使用です。



クラスタシステムの説明は、この記事の範囲外です。 例として、GPFSまたはLustreファイルシステムを使用できます。

メタデータデータベース-自明なデータベース

通常の非クラスターバージョンのSambaは、Trivial Database（TDB）と呼ばれる非常にシンプルでリソースのないデータベースを使用してデータを保存します。



TDBはKey-to-Valueに基づいて構成されており、構成はBerkley DBに似ています。 TDBは、POSIXシステムのさまざまなプロセスからの非常に高速な複数の読み取りおよび書き込みアクセスを提供します。 メモリリフレクション（mmap）は、ほとんどのアーキテクチャでサポートされています。



ファイルシステムへの各クライアント接続は、独自のsmbdデーモンプロセスによって処理されます。 それらの間で、これらのプロセスはTDBベースを介して相互作用します。



SAMBAのクラスターバージョンを実装する最初の試みは、GPFSやLustreなどのクラスターファイルシステムにTDBを含むファイルを単に配置することでした。



このようなSAMBA実装は機能しましたが、非常に低速でした。 速度の低下は、クラスターファイルシステム同期プロトコルのオーバーヘッドと遅延が大きいためです。 同時に、Sambaを正常に動作させるには、TDBへの非常に高速なアクセスを提供する必要があります。



クラスタファイルシステムの機能の基礎は、データを損失から保護することです。 クライアントがデータの記録を開始し、データが書き込まれるはずのノードで障害が発生しても、それらは失われません。



したがって、クラスターファイルシステムは、共有ストレージにデータを書き込むか、クラスター内のすべてのノードに変更を送信する必要があります。



ただし、このステートメントはSambaメタデータに完全に当てはまるわけではありません。 特定の状況では、このデータが失われても、CIFSとPOSIXの間で必要なセマンティクス変換を実行する機能には影響しません。



したがって、記録中に共通のメタデータリポジトリとデータレプリケーションを必要としないクラスターシステムを実装することが可能になります。



これはすべてのメタデータに当てはまるわけではないと言ってください。



TDBデータベースには、永続と非永続の2種類があります。



永続的-再起動後も保持されるべき長期情報が含まれています。 これらのデータベースは、書き込みよりも読み取りによく使用されます。 このタイプのデータベースの書き込みアクセス速度は重要ではありません。 ここでの主なものは信頼性です。



揮発性 -ロックまたはセッションのデータベースなど。 ここに保存されるデータのライフサイクルは短いです。 これらのデータベースへの書き込み頻度は非常に高いです。 また、「通常のTDB」とも呼ばれます。



Sambaが正常に機能するためには、「通常のTDB」で作業する際の高いパフォーマンスが特に重要です。



情報の損失は、一貫性のないデータベースでのみ可能です。



以下の表は、Sambaのクラスター実装で使用されるデータベースのリストと説明です。



表1永続的なTDB

名	記述
account_policy	パスワードの有効期限設定を含む、Samba / NTアカウントポリシー設定。
group_mapping	UNIXグループのWindowsグループ/ SIDマッピングテーブル。
passdb	tdbsamを使用する場合にのみあります。 このファイルには、SambaSAMAccount情報が格納されます。 このファイルでは、POSIXユーザーアカウント情報に/ etc / passwdファイルまたは別のシステムソースからアクセスできる必要があることに注意してください。
登録	Windowsレジストリのスケルトンを格納する読み取り専用のSambaデータベース。winregRPC（リモートプロシージャコール）を介してさまざまなデータベーステーブルのエクスポートをサポートします。
秘密	このファイルには、ワークグループ/ドメイン/コンピューターのSID、LDAPディレクトリを更新するためのパスワード、およびSambaが正しく機能するために必要なその他の重要な環境情報が格納されます。 このファイルには、保護する必要がある非常に重要な情報が含まれています。 PRIVATE_DIRディレクトリに保存されます。
share_info	各リソースのACL情報を保存します。
Idmap2	IDMAP Winbinddデータベース。

表2 TDB

名	記述
ブロック	バイト範囲ロックに関する情報。
ロック	ファイルシステムロックテーブル
接続	接続の最大数を追跡するために使用される現在の接続情報の一時キャッシュ。
Notify_onelevel	おそらくctdbデーモン間のメッセージングに使用されます
通知する	おそらくctdbデーモン間のメッセージングに使用されます
セッションID	さまざまなセッション情報およびutmpサービスの一時キャッシュ。

したがって、どの情報が失われる可能性があるかがわかります。 この情報は、セッション、ロック、および明らかに（インターネット上にはデータがありません）、クラスターの操作に必要な特定の情報に関するものです。



ノードに障害が発生すると、そのノードで開かれているすべてのファイルが閉じられるため、上記の情報が失われることは重要ではありません。

CTDBDデーモンとクラスター内のTDBデータベースの操作

Sambaクラスターの重要なコンポーネントはCTDBDデーモンです。 CTDB（Cluster Trivial DataBase）と呼ばれるクラスター化されたTDBデータベースのサポートを提供し、自動回復の可能性を備えています。



CTDBDはクラスターノードも監視し、障害が発生した場合に自動再構成を実行します。

負荷分散の確保は、CTDBDのもう1つのタスクです。



データベースのタイプに応じて、その処理はさまざまな方法で実行されます。

一時TDBを使用する

一時TDBの主要な機能は、クラスター内のすべてのレコードを含める必要がないことです。 ほとんどの場合、一時TDBには、この特定のノードの接続に関連するエントリのみが含まれます。 したがって、データが落ちた場合、このデータのみが失われます。



CTDBシステムは、各ノードのCTDBDデーモン間のメタデータデータベースの操作に分散プロトコルを使用し、SambaデーモンとCTDBDデーモン間のノード内通信用のローカルプロトコルを使用します。



CTDBの設計では、2層のレコードストレージシステムを使用しています。 最初のレベルでは、各レコードについて、場所の所有者が決定されます-「場所マスター」。 このホストは、そのキーによってレコードに接続されます。



2番目のレベルでは、ロービング「データマスタ」が定義されます（ローミングまたはローミングデータマスタ）。 これは、レコードを変更した最後のノードです。







「ロケーションマスター」は、レコードがどのノードにあるか、したがってどのノードが「データマスター」であるかを常に認識しています。 「データマスタ」には、レコードの最新のコピーが含まれています。



各レコードには、グローバルシリアル番号（RSN（レコードシーケンス番号））が含まれています。これは、「データマスタ」がノードからノードに移動するたびに増加する64ビット整数です。 「データマスター」レコードの所有権の変更は、常に「ロケーションマスター」を通じて行われます。



ノードには、ローカルTDB内の既にアクセス権のあるエントリのみが含まれています。 データは他のノードに自動的に配信されませんが、リクエストに応じてのみ送信できます。



レコードの実際のコピーを含むノードは1つだけです-「データマスター」。 ノードがレコードの書き込みまたは読み取りを行う場合、まず、そのノードの「データマスター」であるかどうかを確認します。 その場合、TDBに直接書き込みます。 そうでない場合、彼はレコードの現在の内容を現在の「データマスター」に要求し、「データマスター」の役割を果たしてから、直接録音を実行します。



したがって、データの書き込みと読み取りは常にローカルで行われ、パフォーマンスが大幅に向上します。



ノードが停止すると、そのノードが「データマスター」であったレコードは失われます。



CTDBDは回復プロセスを開始します。 これを行うには、回復プロセスのマスターノード（「回復マスター」）を選択します。 ノードが選択されると、クラスター化されたファイルシステムで特定のファイル（構成で指定）にロックを設定し、他のノードが「回復マスター」の役割を要求できないようにします。



Recover Masterは、すべてのサイトから最新バージョンのレコードを収集します。 関連性は、RSNの値によって決まります。 最も重要なのは、大きなRSNを持つレコードです。

定数TDBを使用する

このデータベースの場合、各ノードには常にデータベースの完全な現在のコピーがあります。



読み取りは常にローカルコピーから行われます。 ノードが記録する必要がある場合、すべてのノードでデータベース全体を完全にロックするトランザクションを実行します。



次に、必要な記録操作を実行します。 その後、変更はすべてのノード上のデータベースのローカルコピーに記録され、トランザクションは終了します。



したがって、クラスターのすべてのノードには、常にデータベースの完全かつ最新のコピーが含まれています。 これらのデータベースでは変更の頻度が低いため、同期プロセス中に発生する遅延は重要ではありません。



ノードの1つに障害が発生した場合、必要な情報はすべてクラスターの他のメンバーにあります。

ネットワークフェイルオーバー

メタデータデータベースの保護に加えて、CTDBDは統合されたTCP / IPプロトコルフェールオーバーメカニズムを使用します。

これは、クラスターのノード全体に分散されているパブリックIPアドレスのセットのクラスターを使用することにあります。 これらのアドレスは、アドレス解決プロトコル（ARP）の更新を通じてノードからノードに転送できます。



ノードに障害が発生した場合、すべてのパブリックIPアドレスが動作中のノードに転送されます。



パブリックは、顧客が連絡するアドレスです。 クラスターのブライドル間の通信には、内部IPアドレスが使用されます。



別のIPアドレスを引き継いだノードは、古いTCP接続に関する情報のみを知っており、接続の「TCPシーケンス番号」を知りません。 したがって、継続できません。 クライアントと同様に、接続が別のノードに確立されたことを知りません。



接続の切り替えに関連する遅延を回避するために、次の手法が使用されます。 この手法を理解するには、TCPプロトコルの機能の基本原則を理解する必要があります。



IPアドレスを受信すると、新しいノードは、ACKフラグと明らかに間違った「シーケンス番号」がゼロに等しいパケットをクライアントに送信します。 応答として、クライアントは、TCPプロトコルの規則に従って、正しい「シーケンス番号」でACK応答パケットを送り返します。 正しい「シーケンス番号」を受信すると、ノードはRSTフラグとこの「シーケンス番号」でパケットを形成します。 受信すると、クライアントはすぐに接続を再開します。



遅延はごくわずかです。 この手法がないと、クライアントはサーバーからのTCP ACKパケットを長時間待つことができます。

実際に

前述のように、ノードの1つに障害が発生してIPアドレスが転送された場合、障害が発生した後も引き続き動作する責任はすべてクライアントにあります。 障害が発生したノードに関連付けられている開いているファイルはすべて閉じられます。



Windowsエクスプローラーでファイルをコピーまたは読み取る場合、失敗するとエラーが表示されます。 ただし、接続が失われた後に接続を再開できるツールを使用すると、すべてがスムーズに進みます。 たとえば、「/ z」スイッチを使用したxcopyユーティリティ。 このユーティリティを使用してファイルをコピーすると、IPアドレスの切り替え中にわずかな遅延しか発生しません。 その後、コピーが続行されます。



ネットワークリソースへの接続も失われません。



エディターでファイルを開き、IPアドレスを移動するために保存する必要がない場合、失敗しても作業に影響しません。



したがって、この場合の障害後の作業の復元の責任の一部は、クライアントに転送されます。

Sambaクラスターの構成



クラスターのセットアップは、2つのステップで構成されます。

• クラスターで動作するようにSambaデーモンを構成する
• CTDBを構成する

Sambaおよび関連サービスの構成

バージョン3.3以降、Sambaソーステストには組み込みのクラスタリングサポートがあります。 ただし、クラスターで動作するには、特別なキーを使用してパッケージをコンパイルする必要があります。



一般的なディストリビューション（RHEL、SLES、Debian）の場合、 Enterprisesamba.comからクラスタリングサポート付きのコンパイル済みバージョンのSambaをダウンロードできます。



重要なお知らせ。 WindowsクライアントがSambaクラスターで正常に認証されるためには、外部認証を使用することをお勧めします。 たとえば、Active Directoryを使用します。



WindowsユーザーがPosixファイルシステムにアクセスするために、SambaはWindowsユーザーとPOSIXシステムユーザー（Linuxなど）の間のマッピングを確立します。 Windowsユーザーは、既知のPOSIXオペレーティングシステムユーザーの名前でPOSIXファイルシステムにアクセスする必要があります。 Windowsユーザー認証は、POSIX OSのユーザー認証に関係なく発生します。



つまり Windowsユーザーがアクセスできるようにするには、以下を行う必要があります。

• Windowsユーザーが作業するPOSIXオペレーティングシステムでローカルユーザーを作成する
• SambaデータベースにWindowsユーザーを作成し、そのパスワードを設定します
• これらのユーザー間の接続を確立します

ユーザーとパスワードの関係の表は、CTDBデータベースに保存して、クラスター内に配布できます。 ただし、ローカルユーザーデータベースにはこの機能はありません。 つまり Sambaでユーザーを作成するたびに、クラスターのすべてのノードで対応するローカルアカウントを作成する必要があります。



これは不便です。 これを回避するには、外部データベースをローカルユーザーデータベースと併用するのが理にかなっています。 この場合、Active Directotyとの統合が使用されます。 Sambaクラスターはドメインのメンバーです。



ファイル/etc/nsswitch.confに以下を記述する必要があります。

passwd：ファイルwinbind

グループ：ファイルwinbind

シャドウ：ファイルwinbind



これは、ローカルファイルに加えて、ユーザーとグループがwinbindを介してActive Directoryで検索されることを意味します。 winbindサービスを使用すると、WindowsドメインのユーザーがUnixマシンにログインできます。 したがって、透過的なアクセス制御が実装されます。

Active Directoryドメインでの承認は、Kerberosプロトコルの下で実行されます。 Kerberosライブラリ-「/etc/krb5.conf」に適切な設定を行う必要があります。



[ロギング]

デフォルト= FILE：/var/log/krb5libs.log

kdc =ファイル：/var/log/krb5kdc.log

admin_server = FILE：/var/log/kadmind.log



[libdefaults]

default_realm = IT-DYNAMICS.RU-Active Directoryドメイン

dns_lookup_realm = true-サーバーを手動で登録する必要がなくなります

dns_lookup_kdc = true-サーバーを手動で登録する必要がなくなります

ticket_lifetime = 24h

転送可能=はい



[domain_realm]

.it-dynamics.ru = IT-DYNAMICS.RU

.it-dynamics.ru = IT-DYNAMICS.RU



[デフォルト]

pam = {

デバッグ= false

ticket_lifetime = 36000

renew_lifetime = 36000

転送可能= true

krb4_convert = false

}

最後に、Samba自体を構成する必要があります。

[グローバル]

クラスタリング=はい

netbios名= smbcluster

ワークグループ= otd100



セキュリティ= ADS

レルム= IT-DYNAMICS.RU

パスワードの暗号化=はい

クライアントランマン認証= no

クライアントntlmv2 auth = yes



passdbバックエンド= tdbsam

groupdb：バックエンド= tdb

idmapバックエンド= tdb2

idmap uid = 1000000-2000000

idmap gid = 1000000-2000000

fileid：アルゴリズム= fsname

vfsオブジェクト= gpfs​​ fileid

gpfs：sharemodes =いいえ

不明なACLユーザーを強制する=はい

nfs4：モード=特別

nfs4：chown = yes

nfs4：acedub = merge

レジストリ共有=はい



/etc/samba/smb.confの重要なパラメーターは「clustering = yes」です。 クラスタリングのサポートが含まれています。 「netbios name」パラメーターには、すべてのノードに共通するクラスターの名前を記述します。



共有リソースを透過的に管理するには、Samba設定でレジストリサポートを有効にする必要があります-「レジストリ共有= yes」。 それ以外の場合、パブリックフォルダー設定がsmb.confに含まれていると、クラスター内のすべてのノード間でこのファイルを強制的に同期します。



いずれにしても、「/ etc / samba / smb.conf」はすべてのノードで同じである必要があります。



ユーザー認証を成功させるには、次のコマンドでSambaクラスターをActive Directoryドメインに入力する必要があります。net ads join -U Administrator

「管理者」とは、コンピューターをドメインに追加する権限を持つユーザーです。

CTDBを構成する

CTDBは別のパッケージとして提供されます。 ソースはctdb.samba.orgからダウンロードできます。 RHEL x64用のコンパイル済みバージョンもここにあります。 x86の場合、src.rpmをダウンロードして自分でコンパイルできます。



CTDBオプションは/etc/sysconfig/ctdb.confファイルにあります



このファイルは、クラスターのすべてのノードで同じでなければなりません。



最も重要なパラメーター：



CTDB_RECOVERY_LOCK = / gpfs​​-storage / ctdb /ロック

障害から回復するときに「回復マスター」を選択するときに使用されるロックファイルの場所を決定します。 ロックをサポートするクラスター化されたファイルシステムに配置する必要があります。



CTDB_PUBLIC_INTERFACE = eth1

クライアントがクラスターと対話するためのインターフェース。



CTDB_PUBLIC_ADDRESSES = / etc / ctdb / public_addressesクラスターが操作される可能性のあるパブリックIPアドレスを含むファイルへのパス。



CTDB_MANAGES_SAMBA =はい

CTDBデーモンは、Sambaサービスを管理します。 これは、Sambaがクラスターで正しく動作するのに便利です。 CTDB自体は、必要に応じてSambaを起動またはシャットダウンします。 同時に、Sambaをスタートアップから削除する必要があります。



CTDB_MANAGES_WINBIND =はい

前のケースと同様-Winbind管理。



CTDB_NODES = / etc / ctdb /ノード

クラスターの内部キャッチアドレスのリスト。 ノードファイルは、すべてのノードで一意である必要があります。



ファイル/ etc / ctdb / public_addressesで、クライアントを接続するために可能なすべてのパブリックIPアドレスを指定する必要があります。



ファイル/ etc / ctdb / nodesで、クラスター内のすべてのノードの内部IPアドレスを指定する必要があります。

負荷分散

負荷を分散する方法は2つあります。

1. ラウンドロビンDNSの使用
2. LVS

すぐに、どの方法もサーバー負荷に応じてバランスを取ることはできないことに注意してください。 概して、クラスターの異なるノードにクライアントを順次リダイレクトするために、バランシングが削減されます。

ラウンドロビンDNSの分散

この場合、1つのクラスター名に対して複数のIPアドレスがDNSに登録されます。 クライアントがDNSサーバーにアクセスすると、クライアントは異なるクラスターIPアドレスを提供します。 したがって、後続の各クライアントは新しいIPアドレスなどに円で接続します。

LVSバランシング

この場合、クラスター全体が単一のIPアドレスを介してクライアントに提示されます。 ノードの1つがLVSMasterとして選択されます。 クラスターIPアドレスが割り当てられます。 すべてのクライアントがこのアドレスにリクエストを送信します。 次に、LVSMasterは要求をノードの1つにリダイレクトします。 ノードは、LVSMasterを使用せずにクライアントに直接応答します。



LVSを使用するスキームは、複数の読み取り操作で非常に良い結果をもたらすことができます。 書き込み操作中は、すべてがLVSMasterの速度とネットワーク帯域幅に依存します。

クラスター管理

管理は、ctdbコマンドを使用して実行されます。 デフォルトでは、現在のノードで実行されます。 「-n」スイッチを使用すると、別のノードを指定できます。



Ctdbステータス -クラスターステータスを返します

ノードの数：2

pnn：0 172.0.16.101 OK

pnn：1 172.0.16.102 OK（このノード）

世代：985898984

サイズ：2

ハッシュ：0 lmaster：0

ハッシュ：1 lmaster：1

回復モード：通常（0）

回復マスター：0



ノードの状態は次のとおりです。

• OK-通常の操作
• DISCONNECTED-ノードは物理的にアクセスできません
• 無効-ノードは管理者によって無効にされています。 同時に、クラスタ内で動作しますが、そのパブリックIPアドレスは他のノードに転送され、サービスは実行されません。 ただし、ノードはTDBデータベースの一部を提供できます。
• 不健康-ノードの動作に問題があります。 CTDBデーモンは正​​常に機能していますが、パブリックIPは他のノードに転送され、サービスは機能していません。
• 禁止-ノードは回復を頻繁に試行し、一定期間切断されました。 この期間が終了すると、ノードは自動的に操作に戻ります。
• 停止-ノードは停止しており、クラスターに参加していませんが、制御コマンドを受信できます。
• PARTIALLYONLINE-ホストは動作していますが、パブリックIPアドレスを提供するインターフェイスの一部がオフになっています。 少なくとも1つのインターフェースが使用可能でなければなりません。
• 回復モード-クラスター操作モード：
• NORMAL-動作モード
• 回復-クラスターは回復モードです。 すべてのクラスターデータベースがロックされています。 サービスが機能しません。

復旧マスター-復旧ウィザードで選択されたノード



Ctdb IPは、クラスターのパブリックIPアドレスとノードごとのそれらの分布を表示します



ノード1のパブリックIP

128.0.16.110ノード[1]アクティブ[eth0]利用可能[eth0]構成済み[eth0]

128.0.16.111ノード[0]アクティブ[]利用可能[eth0]構成[eth0]



最初の行は、コマンドが実行される現在のノードです。



Ctdb pnn-コマンドが実行されるノード番号を表示します



Ctdb disable-現在のノードを無効に設定します



Ctdbの有効化 -無効化からの戻り



Ctdb stop-現在のノードを停止位置に移動します（クラスターが再構成されます）



Ctdb続行 -停止位置から戻る（クラスターが再構成します）



moveip public_ipノードは、パブリックIPアドレスをあるノードから別のノードに手動で転送します



ctdb getdbmap -CTDBデータベースのリストを表示します。



データベースの数：13

dbid：0x1c904dfd名前：notify_onelevel.tdbパス：/var/ctdb/notify_onelevel.tdb.0

dbid：0x435d3410名前：notify.tdbパス：/var/ctdb/notify.tdb.0

dbid：0x42fe72c5名前：locking.tdbパス：/var/ctdb/locking.tdb.0

dbid：0x1421fb78名前：brlock.tdbパス：/var/ctdb/brlock.tdb.0

dbid：0xc0bdde6a名前：sessionid.tdbパス：/var/ctdb/sessionid.tdb.0

dbid：0x17055d90名前：connections.tdbパス：/var/ctdb/connections.tdb.0

dbid：0xf2a58948名前：registry.tdbパス：/var/ctdb/persistent/registry.tdb.0 PERSISTENT

dbid：0x63501287名前：share_info.tdbパス：/var/ctdb/persistent/share_info.tdb.0 PERSISTENT

dbid：0x92380e87名前：account_policy.tdbパス：/var/ctdb/persistent/account_policy.tdb.0 PERSISTENT

dbid：0x7bbbd26c名前：passdb.tdbパス：/var/ctdb/persistent/passdb.tdb.0 PERSISTENT

dbid：0x2672a57f名前：idmap2.tdbパス：/var/ctdb/persistent/idmap2.tdb.0 PERSISTENT

dbid：0xe98e08b6名前：group_mapping.tdbパス：/var/ctdb/persistent/group_mapping.tdb.0 PERSISTENT

dbid：0xb775fff6名前：secrets.tdbパス：/var/ctdb/persistent/secrets.tdb.0 PERSISTENT

ctdb shutdown-ctdbデーモンを停止します（service stdb stopと同等）

クラスター監視

フォルダ「/ etc / ctdb」にはスクリプト「notify.sh」があります。 ノードのヘルスステータスが変化するたびに呼び出されます。 たとえば、SNMPトラップを送信したり、管理者に電子メールでメッセージを送信したりできます。

おわりに

この記事では、Sambaの回復力サービスがどのように構成されているかを示しました。 キーポイントは次のとおりです。

• CIFSをPOSIXセマンティクスに変換するプロセスを中断せずに特定のメタデータを失う可能性
• 障害がクライアント側に転送された後の継続的な作業に対する責任の一部
• クラスターノードで開かれたファイルは、障害発生時に閉じられます
• 負荷分散は、負荷に関係なく、クライアントをクラスターの異なるノードに順次リダイレクトすることにより実行されます。