JavaScript is required to for searching.
ナビゲーションリンクをスキップ
印刷ビューの終了
Oracle® ZFS Storage Appliance 管理ガイド
Oracle Technology Network
ライブラリ
PDF
印刷ビュー
フィードバック
search filter icon
search icon

Document Information

このドキュメントの使用法

 1 Oracle ZFS Storage Appliance の概要

 2 ステータス

 3 初期構成

 4 ネットワーク構成

 5 ストレージ構成

 6 Storage Area Network の構成

 7 ユーザー構成

 8 ZFSSA の設定

 9 警告の構成

 10 クラスタ構成

クラスタの機能と利点

クラスタのデメリット

クラスタの用語

クラスタ化の理解

クラスタ相互接続 I/O

クラスタリソース管理の理解

クラスタのテイクオーバーとフェイルバック

クラスタ化された環境での構成変更

クラスタ化におけるストレージの考慮点

クラスタ化におけるネットワークの考慮点

プライベートのローカル IP インタフェース

クラスタ化における Infiniband の考慮点

クラスタ化における冗長パスのシナリオ

「スプリットブレイン」状態の回避

テイクオーバーの影響の見積もりと削減

BUI を使用したクラスタ構成

クラスタ化の構成

クラスタ化の構成解除

CLI を使用したクラスタ化の構成

クラスタ構成をシャットダウンする

スタンバイヘッドをシャットダウンする

クラスタ化の構成解除

クラスタノードの配線

ZS3-2 クラスタの配線

ZS3-4 および 7x20 クラスタの配線

ストレージシェルフの配線

クラスタ構成の BUI ページ

 11 ZFSSA サービス

 12 シェア、プロジェクト、およびスキーマ

 13 レプリケーション

 14 シャドウ移行

 15 CLI のスクリプト化

 16 保守のワークフロー

 17 統合

索引

クラスタのテイクオーバーとフェイルバック

クラスタ化されたヘッドノードは、常に次の状態のいずれかになります。

Table 10-4  クラスタの状態
状態
アイコン
CLI/BUI の表示
説明
UNCONFIGURED
image:ステータス: 無効
クラスタ化が構成されていません
まったくクラスタ化されていないシステムは、この状態になります。システムが設定中であるか、またはクラスタ設定タスクがまだ完了していません。
OWNER
image:ステータス: オン
アクティブ (テイクオーバーが完了しました)
クラスタ化が構成され、このノードでクラスタ内のすべてのシェアリソースが制御されます。クラスタ設定がユーザーインタフェースから完了した直後、およびそのピアに障害が発生したことが検出されたとき (テイクオーバー後など) に、システムはこの状態に移行します。管理者が手動でフェイルバック操作を実行するまで、この状態のままです。
STRIPPED
image:ステータス: オフ
準備完了 (フェイルバックを待機中)
クラスタ化が構成され、このノードではシェアリソースが制御されません。クラスタ設定がほかのノードのユーザーインタフェースから完了した直後、またはリブート、電源切断、その他の障害が発生したあとに、システムは STRIPPED になります。管理者が手動でフェイルバック操作を実行するまで、ノードはこの状態のままです。
CLUSTERED
image:ステータス: オン
アクティブ
クラスタ化が構成され、両方のノードがリソース割り当てに応じてシェアリソースを所有しています。各ノードが ZFS プールを所有し、CLUSTERED 状態である場合、2 つのノードは「アクティブ/アクティブ」クラスタと一般に呼ばれる状態になります。
-
image:有効
クラスタに再度参加しています...
アプライアンスは最近リブートされたか、内部障害が発生したあとにアプライアンス管理ソフトウェアが再起動しています。リソース状態は再同期化されています。
-
不明 (切断または再起動中)
ピアアプライアンスの電源が切られているかリブート中であるか、クラスタ相互接続リンクがすべて停止しているか、またはクラスタ化がまだ構成されていません。

これらの状態間の遷移は、2 つの操作 (テイクオーバーとフェイルバック) の一部として発生します。

テイクオーバーは常時発生する可能性があります。前述のとおりに、テイクオーバーはピアの障害が検出されるたびに試みられます。クラスタ構成 CLI または BUI を使用して、手動でトリガーすることもできます。これは、テスト目的でも、順次ソフトウェアアップグレードの実行 (1 番目のヘッドはほかのヘッドが古いソフトウェアを実行するサービスを提供している間にアップグレードされ、2 番目のヘッドは新しいソフトウェアが検証されたあとにアップグレードされる) でも役立ちます。最後に、テイクオーバーはヘッドがブートし、そのピアが存在しないことを検出すると発生します。これにより、通常は片方のヘッドで永続的に障害が発生したり、両方のヘッドが一時的に電源を喪失したりするときにサービスを再開できます。

フェイルバックは自動的には発生しません。障害が発生したヘッドが修復されブートされると、そのヘッドはクラスタに再度参加し (すべてのリソースのビュー、プロパティー、および所有権の再同期化)、管理者がフェイルバック操作を実行するまで待機を継続します。そのときまで、元の動作しているヘッドはすべてのサービスの提供を継続します。これにより、ヘッドが本稼動サービスに戻る前に、最初にテイクオーバーをトリガーした問題の詳細な調査、新規ソフトウェアリビジョンの検証、またはその他の管理タスクを実行できます。フェイルバックはクライアントに大きな影響を与えるため、業務固有の要件およびプロセスに応じてスケジュールするようにしてください。例外が 1 つあります。ヘッド A に障害が発生して、ヘッド B がテイクオーバーしたと想定します。ヘッド A がクラスタに再度参加すると、ヘッド B が存在しないか、障害が発生したことが検出された場合にテイクオーバーの対象になります。原則として、元の問題を調査する機会がない場合でも、サービスを提供しないよりは提供する方が適切です。したがって、以前に障害が発生したヘッドへのフェイルバックは自動的には発生しませんが、テイクオーバーはいつでも実行できます。

クラスタを設定すると、初期状態は設定を OWNER 状態で開始したノードと、STRIPPED 状態のその他のノードで構成されます。初期フェイルバック操作を実行して、STRIPPED ノードにシェアリソースのその部分を渡すと、両方のノードが CLUSTERED 状態になります。両方のクラスタノードに障害が発生するか、電源が切られると、同時起動時にノードが調停され、一方が OWNER 状態になり、他方が STRIPPED 状態になります。

フェイルバック中に、すべての外部リソース (ピアに割り当てられたリソース) がエクスポートされ、そのピアによってインポートされます。障害が発生したためにインポートできないプールでは、STRIPPED ノードのリブートがトリガーされます。障害が発生したプールでフェイルバックを試みると、インポート失敗の結果として STRIPPED ノードがリブートする可能性があります。