Oracle ZFS Storage Appliance の概要
Oracle ZFS Storage Appliance の構成
BUI を使用した LACP 集計リンクインタフェースの作成
プローブベースのリンク状態障害検出を使用した IPMP グループの作成
リンク状態のみの障害検出を使用した IPMP グループの作成
BUI を使用した InfiniBand パーティションのデータリンクとインタフェースの作成
BUI を使用したクラスタ化されたコントローラでの VLAN ID なしの VNIC の作成
BUI を使用したクラスタ化されたコントローラでの同じ VLAN ID の VNIC の作成
CLI を使用したマルチホーミングプロパティーの「厳しい」への変更
BUI を使用した LUN と FC イニシエータグループの関連付け
CLI を使用した LUN と FC イニシエーターグループの関連付け
CLI を使用したイニシエータとイニシエータグループの別名のスクリプト作成
CLI を使用した自動生成の IQN を持つ iSCSI ターゲットの追加
CLI を使用した RADIUS 認証を使用する特定の IQN を持つ iSCSI ターゲットの追加
CLI を使用した CHAP 認証を使用する iSCSI イニシエータの追加
BUI を使用した、ダッシュボードの表示のみが可能なユーザーの追加
Oracle ZFS Storage Appliance の設定
クラスタ化されたシステムの一般的な障害モードは、スプリットブレインと呼ばれます。この状況では、クラスタ化された各ヘッドは、そのピアに障害が発生したと見なされ、テイクオーバーが試みられます。追加ロジックが存在しない状況では、診断や修正が困難な予期しない壊滅的な動作が広範囲にわたって発生する可能性があります。この状況は、一般的にヘッドでシェアされた通信媒体に障害が発生することが要因となります。Oracle ZFS Storage Appliance の場合は、クラスタ I/O リンクに障害が発生すると生じます。アプライアンスソフトウェアでは、組み込みトリプルリンク冗長に加えて (テイクオーバーの発生を回避するには、単一リンクのみが必要です)、ヘッドがテイクオーバーを継続する必要があるかどうかを決定するアービトレーション手順も実行されます。
同様の製品では、数多くのアービトレーションメカニズムが採用されています。一般には、定足数ディスク (SCSI 予約を使用) または定足数サーバーを使用する必要があります。追加ハードウェアを必要としない ATA ディスクの使用をサポートするために、Oracle ZFS Storage Appliance は、ストレージファブリック自体に依存する別のアプローチを使用して、必要な相互排他性を提供します。アービトレーションプロセスは、ストレージファブリックに定義済みの順序で表示される各 SAS エクスパンダ上での SAS ZONE LOCK コマンドの実行で構成されます。どちらかのアプライアンスで、このようなすべてのロック取得の試みに成功すると、テイクオーバーが続行されます。他方のアプライアンスは自分自身をリセットします。ブートして、そのピアが到達不能であることを検出したクラスタ化されたアプライアンスは、テイクオーバーを試みて、同じアービトレーションプロセスに移行するため、1 つ以上のクラスタ I/O リンクが復元されるまで、繰り返しリセットされます。これにより、他方のヘッドであとに発生する障害によって、機能停止が延長されることはありません。これらの SAS ゾーンのロックは、フェイルバックが実行されるか、AKCS_OWNER 状態のヘッドがストレージファブリックへの自分のアクセスを最後に更新してから約 10 秒経過すると解除されます。
このアービトレーションメカニズムは単純で、費用がかからず、追加のハードウェアも必要ありませんが、ストレージファブリック内の 1 つ以上の共通 SAS エクスパンダにアクセスしている両方のクラスタ化されたアプライアンスに依存します。通常の状況では、各アプライアンスがすべてのエクスパンダにアクセスし、アービトレーションは 2 つ以上の SAS ゾーンのロックで構成されます。ただし、アプライアンスが共通のエクスパンダにアクセスしない多重障害シナリオが発生する可能性があります。たとえば、2 本の SAS ケーブルが取り除かれるか、ディスクシェルフの電源が切られると、各アプライアンスはエクスパンダの個々のサブネットにアクセスします。この場合、各アプライアンスは正常に到達可能なすべてのエクスパンダをロックし、そのピアに障害が発生したと判断して、テイクオーバーの続行を試みます。これにより、ディスクアフィリエーションの競合や重大なデータ破損のために、回復不能なハングアップに至る可能性があります。
この状況の結果は重大ですが、これは多重障害の場合にしか発生しないことに注意してください (4 つ以上の障害の場合にのみ、しばしば発生します)。Oracle ZFS Storage Appliance に組み込まれたクラスタ化解決方法は、単一障害点なしを実現し、不要なコストや複雑さをシステムに追加せずに、発生しやすい障害からデータと可用性の両方を保護するように設計されています。大規模な多重障害が発生すると、サービスまたはデータあるいはその両方が失われる可能性があります。これは RAID なしのレイアウトでは無制限のディスク障害から保護できないのと同様です。
図 2-26 スプリットブレインの回避
さいわいにも、このような障害シナリオの大部分はヒューマンエラーから発生し、ハードウェアを正しくインストールして、クラスタ設定および管理のベストプラクティスの訓練をスタッフに実施すれば完全に回避できます。管理者は 3 つのすべてのクラスタ I/O リンクが接続され機能していること (図を参照)、およびすべてのストレージ配線がアプライアンスに付属するセットアップポスターで示すとおりに接続されていることを常に確認する必要があります。クラスタを本稼動に移行する前およびそのあとはいつでも、各ディスクシェルフ (図を参照) への 2 つのパスが検出されることが特に重要になります。容量の増加や障害のあるコンポーネントの交換をサポートするために一時的に配線を変更する場合は、当然例外です。管理者は警告を使用して、クラスタ相互接続リンクおよびディスクシェルフパスの状態をモニターし、障害を迅速に修正するようにしてください。適切な接続を保持すると、ハードウェアまたはソフトウェアコンポーネントに障害が発生した場合でも、可用性とデータ整合性の両方が保護されます。
図 2-27 クラスタの 2 つのパス