キャンパスクラスタ内でのストレージベースのデータレプリケーションの使用

ストレージベースのデータレプリケーションは、ストレージデバイスにインストールされているソフトウェアを使用して、キャンパスクラスタと呼ばれるクラスタ内のレプリケーションを管理します。このようなソフトウェアは、特定のストレージデバイスに固有で、障害回復には使用されません。ストレージベースのデータレプリケーションを構成する際には、ストレージデバイスに付属するドキュメントを参照してください。

使用するソフトウェアに応じて、ストレージベースのデータレプリケーションで自動と手動のいずれかのフェイルオーバーを使用できます。Oracle Solaris Cluster では、EMC SRDF ソフトウェアでのレプリケーションで手動と自動の両方のフェイルオーバーをサポートしています。

このセクションでは、キャンパスクラスタで使用されるストレージベースのデータレプリケーションについて説明します。図 1に、2 つのストレージアレイ間でデータがレプリケートされる、2 ルーム構成の例を示します。この構成では、最初のルームにプライマリストレージアレイがあり、これが両方のルームのノードにデータを提供します。また、プライマリストレージアレイは、複製するデータをセカンダリストレージアレイに提供します。

図 1  ストレージベースのデータレプリケーションを装備した 2 ルーム構成

Oracle Solaris Cluster では、EMC SRDF を使用したストレージベースの同期レプリケーションがサポートされています。EMC SRDF では、非同期レプリケーションはサポートされていません。

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

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

キャンパスクラスタ内でストレージベースのデータレプリケーションを使用する際の要件と制限

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

• クラスタを自動フェイルオーバー用に構成する場合は、同期レプリケーションを使用します。

  レプリケートされたボリュームの自動フェイルオーバー用にクラスタを構成する手順については、ストレージベースのレプリケートされたデバイスの構成および管理を参照してください。キャンパスクラスタを設計するための要件の詳細は、Oracle Solaris Cluster Hardware Administration Manual の Shared Data Storageを参照してください。

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

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

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

• データのプライマリコピーのみがクラスタノードに認識されるようにします。それ以外の場合、ボリュームマネージャーはデータのプライマリコピーとセカンダリコピーの両方に同時にアクセスしようとする場合があります。データコピーの可視性の制御については、ストレージアレイに付属するドキュメントを参照してください。

• EMC SRDF では、ユーザーがレプリケートされるデバイスのグループを定義できます。各レプリケーションデバイスグループには、同じ名前の Oracle Solaris Cluster デバイスグループが必要です。

• EMC SRDF を使用し、並列または直列接続された RDF デバイスを備える、3 つのサイトまたは 3 つのデータセンター構成の場合、参加するすべてのクラスタノードで、Solutions Enabler の SYMCLI オプションファイルに次のエントリを追加する必要があります。

  SYMAPI_2SITE_CLUSTER_DG=device-group:rdf-group-number

  このエントリにより、クラスタソフトウェアで、2 つの SRDF 同期サイト間でのアプリケーションの移動を自動化できます。エントリ内の rdf-group-number は、ホストのローカル Symmetrix を 2 番目のサイトの Symmetrix に接続する RDF グループを表します。

  3 つのデータセンター構成の詳細については、Oracle Solaris Cluster 4.3 Geographic Edition Overview の Three-Data-Center (3DC) Topologiesを参照してください。

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

• Solaris Volume Manager for Sun Cluster 複数所有者ディスクセットはサポートされていません。

• EMC SRDF でドミノモードまたは適応型コピーモードを使用しないでください。詳細は、キャンパスクラスタ内でのストレージベースのデータレプリケーションの使用を参照してください。

キャンパスクラスタ内でストレージベースのデータレプリケーションを使用する際の手動回復に関する懸念事項

すべてのキャンパスクラスタと同じように、ストレージベースのデータレプリケーションを使用するクラスタでは、通常、1 つの障害が発生した場合は介入の必要はありません。ただし、手動フェイルオーバーを使用しており、プライマリストレージデバイスを保持するルームが失われている場合 (図 1を参照)、2 ノードクラスタで問題が発生します。残ったノードは定足数デバイスを予約できず、またクラスタメンバーとしてブートできません。このような状況では、クラスタで次の手動介入が必要になります。

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

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

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

ストレージベースのデータレプリケーションを使用する際のベストプラクティス

ストレージベースのデータレプリケーションに EMC SRDF ソフトウェアを使用する場合は、静的デバイスではなく、動的デバイスを使用してください。静的デバイスではレプリケーションプライマリを変更するのに数分かかり、フェイルオーバー時間に影響を与えることがあります。