クラスタ内でのストレージベースのデータ複製の使用

ストレージベースのデータ複製は、ストレージデバイスにインストールされているソフトウェアを使用して、クラスタまたは構内クラスタ内の複製を管理します。このようなソフトウェアは、特定のストレージデバイスに固有で、障害回復には使用されません。ストレージベースのデータ複製を構成する際には、ストレージデバイスに付属するマニュアルを参照してください。

使用するソフトウェアに応じて、ストレージベースのデータ複製を使用して自動または手動いずれかのフェイルオーバーを使用できます。Oracle Solaris Cluster は、Hitachi TrueCopy、Hitachi Universal Replicator、EMC SRDF ソフトウェアによる複製物の手動、自動フェイルオーバーをサポートしています。

この節では、構内クラスタで使用されるストレージベースのデータ複製を説明します。図 4-1 に、2 つのストレージアレイ間でデータが複製される、2 か所に設置されたクラスタ構成の例を示します。この例では、第一の場所に主ストレージアレイがあり、これが両方の場所のノードにデータを提供します。また主ストレージアレイは、複製するデータを二次ストレージアレイに提供します。

図 4-1 ストレージベースのデータ複製を装備した 2 ヶ所に設置されたクラスタ構成

使用するアプリケーションの種類によっては、Hitachi TrueCopy または Hitachi Universal Replicator によるストレージベースのデータ複製を Oracle Solaris Cluster 環境で同期的または非同期に実行できます。構内クラスタで自動フェイルオーバーを実行する場合は、TrueCopy を同期的に使用します。Oracle Solaris Cluster では、EMC SRDF との同期レプリケーションがストレージベースでサポートされています。EMC SRDF に対する非同期レプリケーションはサポート対象外です。

EMC SRDF のドミノモードまたは適応型コピーモードを使用しないでください。ドミノモードでは、ターゲットが使用可能でないとき、ローカルとターゲット SRDF ボリュームをホストで使用できなくなります。適応型コピーモードは、一般的にデータ移行およびデータセンター移行に使用され、障害回復には推奨されません。

リモートストレージデバイスとの通信が失われた場合は、主クラスタ上で動作しているアプリケーションがブロックされるのを回避できるように Fence_level を never または async に指定しておいてください。Fence_level が data または status に指定されている場合、リモートストレージデバイスにコピーできなかった更新が、主ストレージデバイスによって拒否されます。

クラスタ内でストレージベースのデータ複製を使用する際の要件と制限

データの整合性を確保するには、マルチパスおよび適切な RAID パッケージを使用します。次のリストには、ストレージベースのデータ複製を使用するクラスタ構成を実装するための考慮事項が含まれています。

• ノードからノードヘの距離は、Oracle Solaris Cluster Fibre Channel とインターコネクトインフラストラクチャーにより制限されます。現在の制限とサポートされる技術については、Oracle のサービスプロバイダにお問い合わせください。

• 複製されたボリュームを、定足数デバイスとして構成しないでください。共有の複製されていないボリュームにある定足数デバイスを見つけるか、定足数サーバーを使用します。

• データの主コピーのみがクラスタノードに認識されるようにします。このようにしないと、ボリュームマネージャーはデータの主コピーと二次コピーの両方に同時にアクセスしようとする場合があります。データコピーの可視性の制御に関しては、ご使用のストレージアレイに付属するマニュアルを参照してください。

• EMC SRDF、Hitachi TrueCopy、Hitachi Universal Replicator では、ユーザーは複製デバイスのグループを決定することができます。各複製デバイスグループには、同じ名前の Oracle Solaris Cluster デバイスグループが必要です。

• 特定のアプリケーション固有のデータは、非同期データ複製には適さない場合があります。アプリケーションの動作に関する知識を活用して、ストレージデバイス間でアプリケーション固有のデータを複製する最善の方法を決定します。

• クラスタを自動フェイルオーバー用に構成する場合は、同期複製を使用します。

  複製されたボリュームの自動フェイルオーバー用にクラスタを構成する手順については、「ストレージベースの複製されたデバイスの管理」を参照してください。

• クラスタ内で複製している場合、Oracle Real Application Clusters (RAC) は、SRDF、Hitachi TrueCopy、および Hitachi Universal Replicator でサポートされません。ノードの接続先の複製が現在は主複製ではない場合、そのノードに書き込みアクセス権はありません。クラスタのすべてのノードからの直接書き込みアクセス権が必要なスケーラブルアプリケーションは、複製されるデバイスでサポートできません。

• Oracle Solaris Cluster ソフトウェア用の Veritas Cluster Volume Manager (CVM) および複数所有者 Solaris Volume Manager はサポートされていません。

• EMC SRDF でドミノモードまたは適応型コピーモードを使用しないでください。詳細は、「クラスタ内でのストレージベースのデータ複製の使用」を参照してください。

• Hitachi TrueCopy または Hitachi Universal Replicator でデータモードまたはステータスモードを使用しないでください。詳細は、「クラスタ内でのストレージベースのデータ複製の使用」を参照してください。

クラスタ内でストレージベースのデータ複製を使用する際の手動回復に関する懸念事項

すべての構内クラスタと同じように、ストレージベースのデータ複製を使用するクラスタは、通常、1 つの障害が発生した場合はユーザーの操作は必要ありません。ただし、(図 4-1 に示すように) 手動フェイルオーバーを使用し、主ストレージデバイスを保持する空間が失われた場合、2 ノードクラスタでは問題が発生します。残ったノードは定足数デバイスを予約できず、またクラスタメンバーとして起動できません。このような状況では、クラスタには次の手動操作が必要になります。

1. クラスタメンバーとして起動するよう、Oracle のサービスプロバイダが残りのノードを再構成する必要があります。

2. ユーザーまたは Oracle のサービスプロバイダが、二次ストレージデバイスの複製されてない方のボリュームを定足数デバイスとして構成する必要があります。

3. 二次ストレージデバイスを主ストレージとして使用できるよう、ユーザーまたは Oracle のサービスプロバイダが残りのノードを構成する必要があります。 このような再構成には、ボリュームマネージャーボリュームの再構築、データの復元、ストレージボリュームとアプリケーションの関連付けの変更が含まれます。

ストレージベースのデータ複製を使用する際のベストプラクティス

ストレージベースのデータ複製に Hitachi TrueCopy または Hitachi Universal Replicator ソフトウェアを使用するデバイスグループを設定する場合は、次のプラクティスに従ってください。

• 同期複製を使用して、主サイトに障害が発生したときにデータの損失を防ぎます。

• Oracle Solaris Cluster グローバルデバイスグループと horcm 構成ファイルで定義された TrueCopy 複製グループの間に 1 対 1 の関係が存在するようにしてください。 これにより、両方のグループが 1 つの単位としてノードからノードへ移動することができます。

• 同一の複製されたデバイスグループ内にグローバルファイルシステムボリュームとフェイルオーバーファイルシステムボリュームを混在させることはできません。制御方法が異なるためです。グローバルファイルシステムはデバイス構成システム (Device Configuration System、DCS) によって制御され、フェイルオーバーファイルシステムボリュームは HAS+ によって制御されます。それぞれの主ノードが異なるノードである可能性があるため、どのノードを複製の主ノードにすべきかについて衝突が発生します。

• すべての RAID マネージャーインスタンスが常に起動され実行中であるべきです。

ストレージベースのデータ複製に EMC SRDF ソフトウェアを使用する場合は、静的デバイスではなく動的デバイスを使用します。静的デバイスでは主複製を変更するのに数分かかり、フェイルオーバー時間に影響を与えることがあります。