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 統合

索引

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

ネットワークデバイス、データリンク、およびインタフェースに障害が発生しても、クラスタ化サブシステムではヘッドに障害が発生しません。アプライアンスの内部または外部で発生したネットワーク障害から保護するには、IPMP または LACP あるいはその両方を使用する必要があります。可用性に対する包括的なアプローチには、ネットワークの正しい構成、およびネットワーク全体の冗長化計画が必要です。

Figure 10-5  ネットワークのクラスタ化

image:イメージ

ネットワークインタフェースに静的な IP 構成が含まれる場合は、シングルトンリソースとプライベートリソースのどちらかとして構成できます。DHCP を使用して構成したインタフェースはプライベートにする必要があり、クラスタで DHCP を使用することは推奨されていません。シングルトンリソースとして構成された場合、インタフェースの構築に使用されるすべてのデータリンクおよびデバイスは、一度に 1 つのヘッドでのみアクティブにできます。同様に、フェイルオーバー状態でサービスを提供するには、各ヘッド上の対応するデバイスを同じネットワークに接続する必要があります。この例は前の図で示しています。

ネットワークインタフェースをデバイスおよびデータリンクから構成する場合は、クラスタが正しく動作するように、各シングルトンインタフェースに同じ識別子を使用するデバイス、および両方のヘッドで使用可能な機能が含まれることが重要になります。デバイス識別子はデバイスタイプおよび最初にアプライアンスで検出される順序によって異なるため、クラスタ化されたヘッドに同じハードウェアをインストールする必要があります。両方のヘッドの各スロットには同じハードウェアを装着する必要があり、両方のヘッドにはスロットを同じ順序で装着する必要があります。公認の Oracle 再販業者またはサービス担当者は、これらの要件を満たすハードウェアアップグレードの計画を支援できます。

常に、ルートは明示的に単一のネットワークインタフェースにバインドされます。ルートはリソースマネージャー内でシンビオートとして表現され、バインド先のインタフェースが運用可能なときにのみアクティブにできます。したがって、現在スタンバイモードのインタフェースにバインドされたルート (エクスポート済み) は、そのインタフェースがテイクオーバープロセス中に有効化されるまで無効です。これは、2 つのプールが構成され、共通のサブネットで使用可能にされる場合に重要です。サブネットが、ほかの 1 つ以上のネットワークに到達するためにアプライアンスで使用されるルーターのホームであれば、個別のルート (たとえば、2 番目のデフォルトルート) を構成して、そのサブネットに接続するアクティブおよびスタンバイの各インタフェースにバインドする必要があります。

例:

クラスタ化された各ヘッドに、管理でのみ使用される IP アドレス (ほとんどの場合は専用の管理ネットワーク上にある) を割り当て、インタフェースをプライベートリソースとして指定することはよい方法です。これにより、AKCS_STRIPPED 状態で、フェイルバックの待機中である場合でも、管理ネットワークから動作中のヘッドに到達できるようになります。これが重要なのは、ヘッドはサービスを提供していない場合でも、サービス (LDAP や Active Directory など) が使用中で、ほかのネットワークリソースへのアクセスが必要な場合です。これが現実的でない場合は、システムコンソールを使用してヘッドを管理できるように、信用できるネットワークまたはシリアル端末あるいはその両方にサービスプロセッサを接続する必要があります。

これらのアクションのどちらも実行しない場合は、フェイルバックが完了するまで、新規にブートしたヘッドの管理またはモニターができません。特定のストレージプール用のサービスを提供しているヘッドをモニターまたは管理することが必要な場合があります。これが役立つ可能性が高いのは、ストレージ自体の一部を変更 (シェアプロパティーの変更や新規 LUN の作成など) する必要がある場合です。これを行うには、管理タスクを実行するサービスインタフェースのいずれかを使用するか、一致するプールを管理するためにのみ使用される個別のシングルトンインタフェースを割り当てます。どちらの場合でも、管理に使用されるプールと同じヘッドにインタフェースを割り当てるようにしてください。