第 4 章 データ複製のアプローチ

この章では、Sun Cluster で利用可能なデータ複製のアプローチについて説明します。クラスタに最適なサービスを提供する複製アプローチの組み合わせを選択するためには、ホストベースとストレージベースのデータ複製を両方とも理解しておく必要があります。

Sun Cluster のこのリリースは、Sun の Availability Suite ソフトウェアの次のリリースをサポートしています。

• Sun StorageTek Availability Suite 4

• Sun StorEdge Availability Suite 3.2.1

このマニュアルでは、特に明記していないかぎり、Sun StorageTek Availability Suite ソフトウェアに言及している内容は、Sun StorEdge Availability Suite ソフトウェアにも該当します。

この章の内容は次のとおりです。

• 「データ複製についての理解」

• 「ホストベースのデータ複製の使用法」

• 「ストレージベースのデータ複製の使用法」

• 「例: Sun StorEdge Availability Suite または Sun StorageTek Availability Suite ソフトウェアを使用したホストベースのデータ複製の構成」

データ複製についての理解

「データ複製」とは、主ストレージデバイスからバックアップまたは二次ストレージデバイスへのデータのコピーです。 主デバイスに障害が発生した場合も、二次デバイスからデータを使用できます。このようにして、データ複製を使用すると、クラスタの高可用性と耐災害性を確保できます。

Sun Cluster はデータ複製に対して次のアプローチをサポートしています。

• 「ホストベースのデータ複製」では、特別なソフトウェアを使用して、地理的に離れたノード間でディスクボリュームをリアルタイムに複製します。リモートミラー複製を使用すると、主ノードのマスターボリュームのデータを、地理的に離れた二次ノードのマスターボリュームに複製できます。リモートミラービットマップは、主ディスク上のマスターボリュームと、二次ディスク上のマスターボリュームの差分を追跡します。

  ホストベースのデータ複製は、ストレージアレイを必要としないため、比較的安価なデータ複製ソリューションです。ホストベースのデータ複製は、ローカルに接続されたディスクを使用します。ただし、ホストベースのデータ複製はデータの複製にホストのリソースを消費します。また、Oracle RAC などのスケーラブルアプリケーションをサポートしません。構内クラスタ環境でのホストベースのデータ複製の使用法の詳細については、「ホストベースのデータ複製の使用法」を参照してください。2 つ以上のクラスタ間でのホストベースのデータ複製の使用法についての詳細は、『Sun Cluster Geographic Edition Data Replication Guide for Hitachi TrueCopy 』を参照してください。

• 「ストレージベースのデータ複製」は、特別なソフトウェアを使用して、データ複製の作業をクラスタノードからストレージデバイスに移動させます。このソフトウェアリロケーションはノードの処理能力を一部解放し、クラスタの要求にサービスを提供します。ストレージベースのデータ複製は、構内クラスタ構成において特に重要になる場合があります。これは、この種類のデータ複製はスケーラブルアプリケーションをサポートし、ホストの負担を軽減するためです。また、ストレージベースの複製は、Oracle RAC などのスケーラブルアプリケーションもサポートします。構内クラスタ環境でのストレージベースのデータ複製の使用法の詳細については、「ストレージベースのデータ複製の使用法」を参照してください。2 つ以上のクラスタ間でのストレージベースの複製の使用法、およびこの手順を自動化する Sun Cluster GeoEdition 製品についての詳細は、『Sun Cluster Geographic Edition Data Replication Guide for Sun StorageTek Availability Suite 』を参照してください。

Sun StorageTek Availability Suite ソフトウェアは、地理的に離れたクラスタにわたるホストベースのデータ複製のためのメカニズムを提供します。この章の最後にある「例: Sun StorEdge Availability Suite または Sun StorageTek Availability Suite ソフトウェアを使用したホストベースのデータ複製の構成」では、このようなクラスタ構成の完全な例を示します。

ホストベースのデータ複製の使用法

この節では、2 つの場所に設置された構内クラスタにおけるホストベースのデータ複製を説明します。ホストベースのデータ複製を装備した、2 つの場所に設置されたクラスタ構成は次のように定義されます。

• 2 つの独立した空間。

• 各空間にはノード 1 個と複数のディスクサブシステムを配置。

• 空間内のディスクサブシステム間でデータを複製。

• 少なくとも 1 つのディスクサブシステム。これは両方のホストに接続され、定足数デバイスとして使用され、またいずれかの空間にあります。

---

注 –

この節の例は一般的な構内クラスタ構成を示したもので、必須構成や推奨構成を示すものではありません。説明を簡単にするため、図や説明は、構内クラスタリングの理解に固有な機能のみを集中的に扱います。たとえば、パブリックネットワークの Ethernet 接続は示してありません。

---

この構成では、定足数ディスクが失われると、システムは自動的には復旧できなくなります。復旧には Sun のサービスプロバイダによる介入が必要になります。

図 4–1 ホストベースのデータ複製を装備した 2 ヶ所に設置された構内クラスタ (マルチパスなし)

図 4–1 は、標準的な非構内構成に似ています。構内クラスタでは、マルチモードからシングルモードファイバに切り替えるため、ファイバチャネルスイッチが追加されています。

ストレージベースのデータ複製の使用法

ストレージベースのデータ複製は、ストレージデバイスにインストールされているソフトウェアを使用して複製を管理します。このようなソフトウェアは、使用するそれぞれのストレージデバイスに固有なものです。ストレージベースのデータ複製を構成する際には、常に、ストレージデバイスに付属するマニュアルを参照してください。

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

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

通常のクラスタ稼働中、二次ストレージアレイはクラスタからは認識できません。ただし、主ストレージアレイが使用不能になると、Sun のサービスプロバイダにより、二次ストレージアレイを手動でクラスタ内に構成することができます。

---

注 –

図 4–2 に示すように、複製された側ではないボリューム上に定足数デバイスがあります。複製されたボリュームを定足数デバイスとして使用することはできません。

---

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

使用されるアプリケーションの種類に応じて、Sun Cluster 環境では、ストレージベースのデータ複製を同期または非同期に実行できます。

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

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

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

• 複製されたボリュームを、定足数デバイスとして構成しないでください。すべての定足数デバイスは、複製された側ではないボリューム上に配置します。

• データの主コピーのみがクラスタノードに認識されるようにします。このようにしないと、ボリュームマネージャーはデータの主コピーと二次コピーの両方にアクセスしようとする場合があり、二次コピーは読み取り専用であるため、データ破損が発生する可能性があります。

• 複製されたデバイスを使用するディスクグループまたはディスクセットを作成する場合は、ディスクグループ、またはディスクセットと Hitachi TrueCopy レプリカのペアには同じ名前を使用します。

• データコピーの可視性の制御に関しては、ご使用のストレージアレイに付属するマニュアルを参照してください。

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

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

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

ストレージベースの複製を装備した自動フェイルオーバーに関する要件と制限

ストレージベースのデータ複製と自動フェイルオーバーの併用には、次の制限が適用されます。

• Oracle Real Application Clusters (RAC) はサポートされません。

• 同期モードのみがサポートされます。

• 複製されたデバイスは定足数デバイスになることができません。

• CVM および Sun Cluster 用 Solaris ボリュームマネージャーはサポートされません。

ストレージベースのデータ複製を使用する際の手動復旧の考慮事項

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

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

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

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

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

ストレージベースのデータ複製に Hitachi TrueCopy ソフトウェアを使用するデバイスグループを設定する場合は、次の手順を守ってください。

• データの古いコピーへのフェイルオーバーを回避するため、常に最高のフェンスレベル data を使用します。

• リソースグループ 1 つにつき 1 つの Hitachi TrueCopy デバイスグループを作成します。クラスタリソースグループ、クラスタデバイスグループ、VxVM ディスクグループ、および Hitachi TrueCopy デバイスグループの間には一対一の関係が存在すべきです。

• 同一の Hitachi TrueCopy デバイスグループ内にグローバルファイルシステムボリュームとフェイルオーバーファイルシステムボリュームを混在させることはできません。

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

例: Sun StorEdge Availability Suite または Sun StorageTek Availability Suite ソフトウェアを使用したホストベースのデータ複製の構成

この節では、Sun StorageTek Availability Suite 3.1 または 3.2 ソフトウェア、あるいは Sun StorageTek Availability Suite 4.0 ソフトウェアを使用して、ホストベースのデータをクラスタ間で複製する完全な構成例を示します。この例では、NFS アプリケーション用の完全なクラスタ構成を示し、個別のタスクの実行方法に関する詳細情報を提供します。すべてのタスクは大域ゾーンで行うべきです。例には、ほかのアプリケーションやクラスタ構成で必要な手順がすべて含まれているわけではありません。

スーパーユーザーの代わりに役割に基づくアクセス制御 (RBAC) を使用してクラスタノードにアクセスする場合は、すべての Sun Cluster コマンドの承認を提供する RBAC の役割になることができるようにします。ユーザーがスーパーユーザーでない場合、一連のデータ複製手順には、次の Sun Cluster RBAC の承認が必要です。

• solaris.cluster.modify

• solaris.cluster.admin

• solaris.cluster.read

RBAC の役割の使用法の詳細については、第 2 章「Sun Cluster と RBAC」を参照してください。各 Sun Cluster サブコマンドで必要となる RBAC の承認については、Sun Cluster のマニュアルページを参照してください。

クラスタにおける Sun StorageTek Availability Suite ソフトウェアの理解

この節では耐障害性について紹介し、Sun StorageTek Availability Suite ソフトウェアが使用するデータ複製方式について説明します。

耐障害性は、主クラスタで障害が発生した場合に代わりのクラスタ上でアプリケーションを復元するシステムの機能です。耐障害性のベースは、データ複製とフェイルオーバーです。フェイルオーバーとは、主クラスタから二次クラスタへの、リソースグループまたはデバイスグループの自動再配置です。主クラスタに障害が発生した場合でも、アプリケーションとデータは二次クラスタで即座に使用できます。

Sun StorageTek Availability Suite ソフトウェアが使用するデータ複製方式

この節では、Sun StorageTek Availability Suite が使用するリモートミラー複製方式とポイントインタイムスナップショット方式について説明します。このソフトウェアは、 sndradm(1RPC) と iiadm(1II) コマンドを使用してデータを複製します。

リモートミラー複製

図 4–3 は、ミラー複製を示しています。主ディスクのマスターボリュームのデータは、TCP/IP 接続を経由して二次ディスクのマスターボリュームに複製されます。リモートミラービットマップは、主ディスク上のマスターボリュームと、二次ディスク上のマスターボリュームの差分を追跡します。

図 4–3 リモートミラー複製

リモートミラー複製は、リアルタイムに同期で実行することも非同期で実行することもできます。各クラスタの各ボリュームセットはそれぞれ、同期複製または非同期複製に構成できます。

• 同期データ複製では、リモートボリュームが更新されるまで、書き込み操作は完了したとは確認されません。

• 非同期データ複製では、リモートボリュームが更新される前に書き込み操作が完了したと確認されます。非同期データ複製は、長い距離や低い帯域幅で大きな柔軟性を発揮します。

ポイントインタイムスナップショット

図 4–4 は、ポイントインタイムスナップショットを示しています。各ディスクのマスターボリュームのデータは、同じディスクのシャドウボリュームにコピーされます。ポイントインタイムピットマップは、マスターボリュームとシャドウボリューム間の違いを追跡調査します。データがシャドウボリュームにコピーされると、ポイントインタイムビットマップはリセットされます。

図 4–4 ポイントインタイムスナップショット

構成例での複製

図 4–5 に、この構成例でミラー複製とポイントインタイムスナップショットがどのように使用されているかを示します。

図 4–5 構成例での複製

クラスタ間でホストベースのデータ複製を構成するためのガイドライン

この節では、クラスタ間のデータ複製の構成ガイドラインを提供します。また、複製リソースグループとアプリケーションリソースグループの構成のコツも紹介します。これらのガイドラインは、クラスタのデータ複製を構成する際に使用してください。

この節では、次の項目について説明します。

• 「複製リソースグループの構成」

• 「アプリケーションリソースグループの構成」

  • 「フェイルオーバーアプリケーション向けのリソースグループの構成」

  • 「スケーラブルアプリケーション向けのリソースグループの構成」

• 「フェイルオーバーまたはスイッチオーバーの管理ガイドライン」

複製リソースグループの構成

複製リソースグループは、Sun StorageTek Availability Suite ソフトウェアが制御するデバイスグループと論理ホスト名リソースを相互に関連付けます。複製リソースグループには、次の特徴があります。

• フェイルオーバーリソースグループである

  フェイルオーバーリソースは、常に単一のノード上で実行されます。フェイルオーバーが発生すると、フェイルオーバーリソースがフェイルオーバーに加わります。

• 論理ホスト名リソースを持つ

  論理ホスト名は、主クラスタがホストでなければなりません。フェイルオーバーまたはスイッチオーバーの後は、二次クラスタが論理ホスト名のホストになる必要があります。ドメインネームシステム (DNS) は、論理ホスト名とクラスタを関連付けるために使用されます。

• HAStoragePlus リソースを持つ

  HAStoragePlus リソースは、複製リソースグループがスイッチオーバーまたはフェイルオーバーしたときに、デバイスグループをスイッチオーバーします。Sun Cluster ソフトウェアはまた、デバイスグループがスイッチオーバーしたときに、複製リソースグループをスイッチオーバーします。このように複製リソースグループとデバイスグループは常に結び付き、同じノードから制御されます。

  HAStoragePlus リソース内に次の拡張プロパティを定義する必要があります。

  • GlobalDevicePaths。この拡張プロパティは、ボリュームが属するデバイスグループを定義します。

  • AffinityOn property = True。この拡張プロパティは、複製リソースグループがスイッチオーバーまたはフェイルオーバーしたときに、デバイスグループをスイッチオーバーまたはフェイルオーバーします。この機能はアフィニティースイッチオーバーと呼ばれます。

  HAStoragePlus については、SUNW.HAStoragePlus(5) のマニュアルページを参照してください。

• 結び付いているデバイスグループに -stor-rg を付けた名前になる

  たとえば、devgrp-stor-rg などです。

• 主クラスタと二次クラスタでオンラインになる

アプリケーションリソースグループの構成

高可用性を実現するためには、アプリケーションはアプリケーションリソースグループのリソースとして管理される必要があります。アプリケーションリソースグループは、フェイルオーバーアプリケーションまたはスケーラブルアプリケーション向けに構成できます。

主クラスタ上に構成したアプリケーションリソースとアプリケーションリソースグループは、二次クラスタ上でも構成される必要があります。また、アプリケーションリソースがアクセスするデータは、二次クラスタに複製する必要があります。

この節では、次のアプリケーションリソースグループを構成するためのガイドラインを紹介します。

• 「フェイルオーバーアプリケーション向けのリソースグループの構成」

• 「スケーラブルアプリケーション向けのリソースグループの構成」

フェイルオーバーアプリケーション向けのリソースグループの構成

フェイルオーバーアプリケーションでは、1 つのアプリケーションが 1 度に 1 ノード上で動作します。ノードで障害が発生すると、アプリケーションは同じクラスタ内の別のノードにフェイルオーバーします。フェイルオーバーアプリケーション向けリソースグループは、以下の特徴を持っていなければなりません。

• アプリケーションリソースグループがスイッチオーバーまたはフェイルオーバーされた場合、 HAStoragePlus リソースにデバイスグループをスイッチオーバーさせる

  デバイスグループは、複製リソースグループとアプリケーションリソースグループに結び付けられています。したがって、アプリケーションリソースグループがスイッチオーバーすると、デバイスグループと複製リソースグループもスイッチオーバーします。アプリケーションリソースグループ、複製リソースグループおよびデバイスグループは、同じノードによって制御されます。

  ただし、デバイスグループや複製リソースグループがスイッチオーバーまたはフェイルオーバーしても、アプリケーションリソースグループはスイッチオーバーやフェイルオーバーを行いません。

  • アプリケーションデータがグローバルマウントされている場合は、アプリケーションリソースグループに HAStoragePlus リソースを必ず入れなければならないわけではありませんが、入れることをお勧めします。

  • アプリケーションデータがローカルマウントされている場合は、アプリケーションリソースグループに HAStoragePlus リソースを必ず入れなければなりません。

    HAStoragePlus リソースがないと、アプリケーションリソースグループがスイッチオーバーまたはフェイルオーバーしても、複製リソースグループとデバイスグループのスイッチオーバーやフェイルオーバーは行われません。スイッチオーバーやフェイルオーバーの後は、アプリケーションリソースグループ、複製リソースグループおよびデバイスグループは同じノードからは制御されません。

  HAStoragePlus については、SUNW.HAStoragePlus(5) のマニュアルページを参照してください。

• 主クラスタでオンライン、二次クラスタでオフラインとなる

  二次クラスタが主クラスタをテイクオーバーした場合は、二次クラスタ上のアプリケーションリソースグループをオンラインにします。

図 4–6 フェイルオーバーアプリケーションでのアプリケーションリソースグループと複製リソースグループの構成を示す図

図 4–6 フェイルオーバーアプリケーションでのリソースグループの構成

スケーラブルアプリケーション向けのリソースグループの構成

スケーラブルアプリケーションでは、アプリケーションは複数のノードで実行されて、1つの論理サービスを作成します。スケーラブルアプリケーションを実行しているノードで障害が発生しても、フェイルオーバーは起こりません。アプリケーションは別のノードで引き続き実行されます。

スケーラブルアプリケーションをアプリケーションリソースグループのリソースとして管理している場合は、アプリケーションリソースグループをデバイスグループと結び付ける必要はありません。したがって、アプリケーションリソースグループ向けに HAStoragePlus リソースを作成する必要はありません。

スケーラブルアプリケーション向けリソースグループは、以下の特徴を持っていなければなりません。

• 共有アドレスのリソースグループに依存する

  共有アドレスは、受信データを配信するためにスケーラブルアプリケーションを実行するノードで使用されます。

• 主クラスタでオンライン、二次クラスタでオフラインとなる

図 4–7 スケーラブルアプリケーションでのリソースグループの構成を示す図

図 4–7 スケーラブルアプリケーションでのリソースグループの構成

フェイルオーバーまたはスイッチオーバーの管理ガイドライン

主クラスタで障害が発生した場合、できるだけ速やかにアプリケーションを二次クラスタにスイッチオーバーする必要があります。二次クラスタがテイクオーバーできるようにするには、DNS を更新する必要があります。

DNS は、クライアントをアプリケーションの論理ホスト名に関連付けます。フェイルオーバーまたはスイッチオーバーの後、主クラスタへの DNS マッピングを削除し、二次クラスタへの DNS マッピングを作成します。図 4–8 DNS がどのようにクライアントをクラスタにマッピングするかを示す図

図 4–8 クライアントからクラスタへの DNS マッピング

DNS を更新するには、nsupdate コマンドを使用します。詳細は、nsupdate(1M) のマニュアルページを参照してください。フェイルオーバーやスイッチオーバーの管理方法の例については、「フェイルオーバーとスイッチオーバーの管理例」を参照してください。

修復後は、主クラスタをオンラインに戻せます。元の主クラスタにスイッチバックするには、次の手順を実行します。

1. 主クラスタと二次クラスタを同期させ、主ボリュームが最新のものであることを確認します。

2. クライアントが主クラスタのアプリケーションにアクセスできるように、DNS を更新します。

作業マップ: データ複製の構成例

表 4–1 に、Sun StorageTek Availability Suite ソフトウェアを使用して NFS アプリケーション向けにデータ複製を構成する方法の、この例の作業を示します。

表 4–1 作業マップ: データ複製の構成例

作業	参照先
1. クラスタを接続およびインストールする。	「クラスタの接続とインストール」
2. 主クラスタと二次クラスタで、デバイスグループ、NFS アプリケーション用のファイルシステム、およびリソースグループを構成する。	「デバイスグループとリソースグループの構成例」
3. 主クラスタと二次クラスタでデータ複製を有効にする。	「主クラスタで複製を有効にする」 「 二次クラスタで複製を有効にする」
4. データ複製を実行する。	「リモートミラー複製を実行する」 「ポイントインタイムスナップショットを実行する」
5. データ複製の構成を確認する。	「複製が正しく構成されていることを確認する」

クラスタの接続とインストール

図 4–9 に構成例で使用するクラスタ構成を示します。構成例の二次クラスタにはノードが 1 つ含まれていますが、これ以外のクラスタ構成も使用できます。

図 4–9 クラスタ構成例

表 4–2 に、構成例で必要となるハードウェアとソフトウェアをまとめました。Solaris OS、Sun Cluster ソフトウェア、ボリューム管理ソフトウェアは、Sun StorageTek Availability Suite ソフトウェアとパッチをインストールする前にクラスタノードにインストールしてください。

表 4–2 必要なハードウェアとソフトウェア

ハードウェアまたはソフトウェア	要件
ノードハードウェア	Sun StorageTek Availability Suite ソフトウェアは、Solaris OS を使用するすべてのサーバー上でサポートされます。  使用するハードウェアについては、『Sun Cluster 3.1 - 3.2 Hardware Administration Manual for Solaris OS 』を参照してください。
ディスクの空き容量	約 15M バイト
Solaris OS	Sun Cluster ソフトウェアがサポートする Solaris OS のリリース。  すべてのノードが同じバージョンの Solaris OS を使用する必要があります。  インストールの詳細は、『Sun Cluster ソフトウェアのインストール (Solaris OS 版)』を参照してください。
Sun Cluster ソフトウェア	Sun Cluster 3.2 ソフトウェア  インストールの詳細は、『Sun Cluster ソフトウェアのインストール (Solaris OS 版)』を参照してください。
ボリューム管理ソフトウェア	Solstice DiskSuite または Solaris ボリュームマネージャー ソフトウェアまたは VERITAS Volume Manager (VxVM) ソフトウェア  すべてのノードで、同じバージョンのボリューム管理ソフトウェアを使用する。  インストールの詳細は、『Sun Cluster ソフトウェアのインストール (Solaris OS 版)』の第 4 章「Solaris ボリュームマネージャー ソフトウェアの構成」および『Sun Cluster ソフトウェアのインストール (Solaris OS 版)』の第 5 章「VERITAS Volume Manager をインストールして構成する」を参照してください。
Sun StorageTek Availability Suite ソフトウェア	ソフトウェアのインストール方法については、使用しているリリースの Sun StorageTek Availability Suite または Sun StorageTek Availability Suite ソフトウェアのインストールマニュアルを参照してください。  Sun StorEdge Availability Suite 3.1 - Sun StorEdge Availability のマニュアル Sun StorEdge Availability Suite 3.2 - Sun StorEdge Availability のマニュアル Sun StorageTek Availability Suite 4.0 – Sun StorageTek Availability のマニュアル
Sun StorageTek Availability Suite ソフトウェアパッチ	最新のパッチについては、http://www.sunsolve.com を参照

デバイスグループとリソースグループの構成例

この節では、NFS アプリケーション向けにディスクデバイスグループとリソースグループをどのように構成するかを説明します。追加情報については、「複製リソースグループの構成」および「アプリケーションリソースグループの構成」を参照してください。

ここで説明する手順は次のとおりです。

• 「主クラスタでデバイスグループを構成する」

• 「二次クラスタでデバイスグループを構成する」

• 「主クラスタのファイルシステムを NFS アプリケーション向けに構成する」

• 「二次クラスタのファイルシステムを NFS アプリケーション向けに構成する」

• 「主クラスタで複製リソースグループを作成する」

• 「二次クラスタで複製リソースグループを作成する」

• 「主クラスタで NFS アプリケーションリソースグループを作成する」

• 「二次クラスタで NFS アプリケーションリソースグループを作成する」

• 「複製が正しく構成されていることを確認する」

構成例のために作成されたグループとリソースの名前を次の表に示します。

表 4–3 構成例内のグループとリソースのまとめ

グループまたはリソース	名前	説明
デバイスグループ	devgrp	デバイスグループ
複製リソースグループとリソース	devgrp-stor-rg	複製リソースグループ
	lhost-reprg-prim、lhost-reprg-sec	主クラスタと二次クラスタの複製リソースグループの論理ホスト名
	devgrp-stor	複製リソースグループの HAStoragePlus リソース
アプリケーションリソースグループとリソース	nfs-rg	アプリケーションリソースグループ
	lhost-nfsrg-prim、lhost-nfsrg-sec	主クラスタと二次クラスタのアプリケーションリソースグループの論理ホスト名
	nfs-dg-rs	アプリケーションの HAStoragePlus リソース
	nfs-rs	NFS リソース

devgrp-stor-rg 以外のグループとリソースの名前は一例で、必要に応じて変更可能です。複製リソースグループは、devicegroupname-stor-rg というフォーマットでなければなりません。

この構成例では VxVM ソフトウェアを使用しています。Solstice DiskSuite または Solaris ボリュームマネージャー ソフトウェアについては、『Sun Cluster ソフトウェアのインストール (Solaris OS 版)』の第 4 章「Solaris ボリュームマネージャー ソフトウェアの構成」を参照してください。

デバイスグループで作成済みのボリュームを下図に示します。

図 4–10 デバイスグループのボリューム

---

注 –

この手順で定義されたボリュームに、シリンダ 0 などのディスクラベルのプライベート領域を含めてはなりません。VxVM ソフトウェアは、この制限を自動管理します。

---

主クラスタでデバイスグループを構成する

始める前に

次の作業を完成していることを確認してください。

• 次の節のガイドラインと要件を確認します。

  • 「クラスタにおける Sun StorageTek Availability Suite ソフトウェアの理解」

  • 「クラスタ間でホストベースのデータ複製を構成するためのガイドライン」

• 「クラスタの接続とインストール」で説明されているように、主クラスタおよび二次クラスタを設定します。

1. nodeA にスーパーユーザーまたは RBAC の承認 solaris.cluster.modify を提供する役割を使用してアクセスします。

   nodeA は、主クラスタの最初のノードです。どのノードが nodeA であるかを確認するには、図 4–9を参照してください。

2. nodeA でボリューム 1 vol01 からボリューム 4 vol04 を含むディスクグループを作成します。

   VxVM ソフトウェアを使用したディスクグループの構成については、『Sun Cluster ソフトウェアのインストール (Solaris OS 版)』の第 5 章「VERITAS Volume Manager をインストールして構成する」を参照してください。

3. ディスクグループを構成して、デバイスグループを作成します。

   nodeA# cldevicegroup create -t vxvm -n nodeA nodeB devgrp

   デバイスグループは devgrp と呼ばれます。

4. デバイスグループのファイルシステムを作成します。

   nodeA# newfs /dev/vx/rdsk/devgrp/vol01 < /dev/null nodeA# newfs /dev/vx/rdsk/devgrp/vol02 < /dev/null

   vol03 と vol04 は raw ボリュームとして使用されるため、ファイルシステムは必要ありません。

次の手順

「二次クラスタでデバイスグループを構成する」に進みます。

二次クラスタでデバイスグループを構成する

始める前に

手順「主クラスタでデバイスグループを構成する」を完了します。

1. nodeC にスーパーユーザーまたは RBAC の承認 solaris.cluster.modify を提供する役割を使用してアクセスします。

2. nodeC でボリューム 1 vol01 からボリューム 4 vol04 までの 4 つのボリュームを含む ディスクグループを作成します。

3. ディスクグループを構成して、デバイスグループを作成します。

   nodeC# cldevicegroup create -t vxvm -n nodeC devgrp

   デバイスグループは devgrp という名前です。

4. デバイスグループのファイルシステムを作成します。

   nodeC# newfs /dev/vx/rdsk/devgrp/vol01 < /dev/null nodeC# newfs /dev/vx/rdsk/devgrp/vol02 < /dev/null

   vol03 と vol04 は raw ボリュームとして使用されるため、ファイルシステムは必要ありません。

次の手順

「主クラスタのファイルシステムを NFS アプリケーション向けに構成する」に進みます。

主クラスタのファイルシステムを NFS アプリケーション向けに構成する

始める前に

手順「二次クラスタでデバイスグループを構成する」を完了します。

1. nodeA および nodeB で、スーパーユーザーまたは RBAC の承認 solaris.cluster.admin を提供する役割になります。

2. nodeA と nodeB で、NFS ファイルシステム向けのマウントポイントディレクトリを作成します。

   たとえば、次のように指定します。

   nodeA# mkdir /global/mountpoint

3. nodeA と nodeB で、マウントポイントに自動でマウントされるようにマスターボリュームを構成します。

   nodeA と nodeB の /etc/vfstab ファイルに以下のテキストを追加するか、既存のテキストと置き換えます。テキストは 1 行で記述してください。

   /dev/vx/dsk/devgrp/vol01 /dev/vx/rdsk/devgrp/vol01 \ /global/mountpoint ufs 3 no global,logging

   デバイスグループで使用されているボリューム名とボリューム番号を確認するには、図 4–10 を参照してください。

4. nodeA で、Sun Cluster HA for NFS データサービスが使用するファイルのシステム情報向けのボリュームを作成します。

   nodeA# vxassist -g devgrp make vol05 120m disk1

   ボリューム 5 vol05 には Sun Cluster HA for NFS データサービスが使用するファイルシステム情報が含まれています。

5. nodeA で、デバイスグループと Sun Cluster ソフトウェアを再同期化します。

   nodeA# cldevicegroup sync devgrp

6. nodeA で、vol05 用のファイルシステムを作成します。

   nodeA# newfs /dev/vx/rdsk/devgrp/vol05

7. nodeA と nodeB で、vol05 のマウントポイントを作成します。

   次の例では、マウントポイント /global/etc を作成しています。

   nodeA# mkdir /global/etc

8. nodeA と nodeB で、マウントポイントに自動でマウントされるように vol05 を構成します。

   nodeA と nodeB の /etc/vfstab ファイルに以下のテキストを追加するか、既存のテキストと置き換えます。テキストは 1 行で記述してください。

   /dev/vx/dsk/devgrp/vol05 /dev/vx/rdsk/devgrp/vol05 \ /global/etc ufs 3 yes global,logging

9. nodeA に vol05 をマウントします。

   nodeA# mount /global/etc

10. vol05 がリモートシステムからアクセスできるようにします。

    1. nodeA に /global/etc/SUNW.nfs というディレクトリを作成します。

       nodeA# mkdir -p /global/etc/SUNW.nfs

    2. nodeA に /global/etc/SUNW.nfs/dfstab.nfs-rs ファイルを作成します。

       nodeA# touch /global/etc/SUNW.nfs/dfstab.nfs-rs

    3. nodeA の /global/etc/SUNW.nfs/dfstab.nfs-rs ファイルに次の行を追加します。

       share -F nfs -o rw -d "HA NFS" /global/mountpoint

次の手順

「二次クラスタのファイルシステムを NFS アプリケーション向けに構成する」に進みます。

二次クラスタのファイルシステムを NFS アプリケーション向けに構成する

始める前に

手順「主クラスタのファイルシステムを NFS アプリケーション向けに構成する」を完了します。

1. nodeC で、スーパーユーザーまたは RBAC の承認 solaris.cluster.admin を提供する役割になります。

2. nodeC で、NFS ファイルシステム向けのマウントポイントディレクトリを作成します。

   たとえば、次のように指定します。

   nodeC# mkdir /global/mountpoint

3. nodeC で、マウントポイントに自動でマウントされるようにマスターボリュームを構成します。

   nodeC の /etc/vfstab ファイルに以下のテキストを追加するか、既存のテキストと置き換えます。テキストは 1 行で記述してください。

   /dev/vx/dsk/devgrp/vol01 /dev/vx/rdsk/devgrp/vol01 \ /global/mountpoint ufs 3 no global,logging

4. nodeC で、Sun Cluster HA for NFS データサービスが使用するファイルのシステム情報向けのボリュームを作成します。

   nodeC# vxassist -g devgrp make vol05 120m disk1

   ボリューム 5 vol05 には Sun Cluster HA for NFS データサービスが使用するファイルシステム情報が含まれています。

5. nodeC で、デバイスグループと Sun Cluster ソフトウェアを再同期化します。

   nodeC# cldevicegroup sync devgrp

6. nodeC で、vol05 用のファイルシステムを作成します。

   nodeC# newfs /dev/vx/rdsk/devgrp/vol05

7. nodeC で、vol05 用のマウントポイントを作成します。

   次の例では、マウントポイント /global/etc を作成しています。

   nodeC# mkdir /global/etc

8. nodeC で、vol05 がマウントポイントで自動的にマウントされるよう構成します。

   nodeC の /etc/vfstab ファイルに以下のテキストを追加するか、既存のテキストと置き換えます。テキストは 1 行で記述してください。

   /dev/vx/dsk/devgrp/vol05 /dev/vx/rdsk/devgrp/vol05 \ /global/etc ufs 3 yes global,logging

9. nodeC に vol05 をマウントします。

   nodeC# mount /global/etc

10. vol05 がリモートシステムからアクセスできるようにします。

    1. nodeC に /global/etc/SUNW.nfs というディレクトリを作成します。

       nodeC# mkdir -p /global/etc/SUNW.nfs

    2. nodeC に /global/etc/SUNW.nfs/dfstab.nfs-rs ファイルを作成します。

       nodeC# touch /global/etc/SUNW.nfs/dfstab.nfs-rs

    3. nodeC の /global/etc/SUNW.nfs/dfstab.nfs-rs ファイルに次の行を追加します。

       share -F nfs -o rw -d "HA NFS" /global/mountpoint

次の手順

「主クラスタで複製リソースグループを作成する」に進みます。

主クラスタで複製リソースグループを作成する

始める前に

手順「二次クラスタのファイルシステムを NFS アプリケーション向けに構成する」を完了します。

1. nodeA にスーパーユーザーまたは RBAC の承認 solaris.cluster.modify、solaris.cluster.admin、および solaris.cluster.read を提供する役割を使用してアクセスします。

2. SUNW.HAStoragePlus というリソース型を登録します。

   nodeA# clresourcetype register SUNW.HAStoragePlus

3. デバイスグループの複製リソースグループを作成します。

   nodeA# clresourcegroup create -n nodeA,nodeB devgrp-stor-rg

   -n nodeA,nodeB

   クラスタノード nodeA および nodeB が複製リソースグループをマスターできることを指定します。

   devgrp-stor-rg

   複製リソースグループの名前。この名前で、devgrp はデバイスグループの名前を指定します。

4. 複製リソースグループに SUNW.HAStoragePlus リソースを追加します。

   nodeA# clresource create -g devgrp-stor-rg -t SUNW.HAStoragePlus \ -p GlobalDevicePaths=devgrp \ -p AffinityOn=True \ devgrp-stor

   -g

   リソースを追加するリソースグループを指定します。

   -p GlobalDevicePaths=

   Sun StorageTek Availability Suite ソフトウェアが依存する拡張プロパティーを指定します。

   -p AffinityOn=True

   SUNW.HAStoragePlus リソースが、-x GlobalDevicePaths= で定義されたグローバルデバイスおよびクラスタファイルシステムに対して、アフィニティースイッチオーバーを実行することを指定します。したがって、複製リソースグループがフェイルオーバーまたはスイッチオーバーすると、関連デバイスグループがスイッチオーバーします。

   これらの拡張プロパティーについては、SUNW.HAStoragePlus(5) のマニュアルページを参照してください。

5. 論理ホスト名リソースを複製リソースグループに追加します。

   nodeA# clreslogicalhostname create -g devgrp-stor-rg lhost-reprg-prim

   主クラスタ上の複製リソースグループの論理ホスト名は lhost-reprg-prim です。

6. リソースを有効にし、リソースグループを管理し、リソースグループをオンラインにします。

   nodeA# clresourcegroup online -e -M -n nodeA devgrp-stor-rg

   -e

   関連付けられたリソースを有効にします。

   -M

   リソースグループを管理状態にします。

   -n

   リソースグループをオンラインにするノードを指定します。

7. リソースグループがオンラインであることを確認します。

   nodeA# clresourcegroup status devgrp-stor-rg

   リソースグループの状態フィールドを調べ、複製リソースグループが nodeA でオンラインとなっていることを確認します。

次の手順

「二次クラスタで複製リソースグループを作成する」に進みます。

二次クラスタで複製リソースグループを作成する

始める前に

手順「主クラスタで複製リソースグループを作成する」を完了します。

1. nodeC にスーパーユーザーまたは RBAC の承認 solaris.cluster.modify、solaris.cluster.admin、および solaris.cluster.read を提供する役割を使用してアクセスします。

2. SUNW.HAStoragePlus というリソースタイプを登録します。

   nodeC# clresourcetype register SUNW.HAStoragePlus

3. デバイスグループの複製リソースグループを作成します。

   nodeC# clresourcegroup create -n nodeC devgrp-stor-rg

   create

   リソースグループを作成します。

   -n

   リソースグループのノードリストを指定します。

   devgrp

   デバイスグループの名前。

   devgrp-stor-rg

   複製リソースグループの名前。

4. 複製リソースグループに SUNW.HAStoragePlus リソースを追加します。

   nodeC# clresource create \ -t SUNW.HAStoragePlus \ -p GlobalDevicePaths=devgrp \ -p AffinityOn=True \ devgrp-stor

   create

   リソースを作成します。

   -t

   リソースタイプを指定します。

   -p GlobalDevicePaths=

   Sun StorageTek Availability Suite ソフトウェアが依存する拡張プロパティーを指定します。

   -p AffinityOn=True

   SUNW.HAStoragePlus リソースが、-x GlobalDevicePaths= で定義されたグローバルデバイスおよびクラスタファイルシステムに対して、アフィニティースイッチオーバーを実行することを指定します。したがって、複製リソースグループがフェイルオーバーまたはスイッチオーバーすると、関連デバイスグループがスイッチオーバーします。

   devgrp-stor

   複製リソースグループの HAStoragePlus リソース

   これらの拡張プロパティーについては、SUNW.HAStoragePlus(5) のマニュアルページを参照してください。

5. 論理ホスト名リソースを複製リソースグループに追加します。

   nodeC# clreslogicalhostname create -g devgrp-stor-rg lhost-reprg-sec

   主クラスタ上の複製リソースグループの論理ホスト名は lhost-reprg-sec です。

6. リソースを有効にし、リソースグループを管理し、リソースグループをオンラインにします。

   nodeC# clresourcegroup online -e -M -n nodeC devgrp-stor-rg

   online

   オンラインにします。

   -e

   関連付けられたリソースを有効にします。

   -M

   リソースグループを管理状態にします。

   -n

   リソースグループをオンラインにするノードを指定します。

7. リソースグループがオンラインであることを確認します。

   nodeC# clresourcegroup status devgrp-stor-rg

   リソースグループの状態フィールドを調べ、複製リソースグループが nodeC でオンラインとなっていることを確認します。

次の手順

「主クラスタで NFS アプリケーションリソースグループを作成する」に進みます。

主クラスタで NFS アプリケーションリソースグループを作成する

この手順では、アプリケーションリソースグループを NFS に対して作成する方法を説明します。この手順はこのアプリケーションに固有で、別の種類のアプリケーションには使用できません。

始める前に

手順「二次クラスタで複製リソースグループを作成する」を完了します。

1. nodeA にスーパーユーザーまたは RBAC の承認 solaris.cluster.modify、solaris.cluster.admin、および solaris.cluster.read を提供する役割を使用してアクセスします。

2. SUNW.nfs をリソースタイプとして登録します。

   nodeA# clresourcetype register SUNW.nfs

3. SUNW.HAStoragePlus をリソースタイプとして登録していない場合は、登録します。

   nodeA# clresourcetype register SUNW.HAStoragePlus

4. デバイスグループ devgrp のアプリケーションリソースグループを作成します。

   nodeA# clresourcegroup create \ -p Pathprefix=/global/etc \ -p Auto_start_on_new_cluster=False \ -p RG_dependencies=devgrp-stor-rg \ nfs-rg

   Pathprefix=/global/etc

   グループのリソースが管理ファイルを書き込むディレクトリを指定します。

   Auto_start_on_new_cluster=False

   アプリケーションリソースグループが自動的に起動しないように指定します。

   RG_dependencies=devgrp-stor-rg

   アプリケーションリソースグループが依存するリソースグループを指定します。この例では、アプリケーションリソースグループは複製リソースグループ devgrp-stor-rg に依存しています。

   アプリケーションリソースグループが新しい主ノードにスイッチオーバーすると、複製リソースグループが自動的にスイッチオーバーします。ただし、複製リソースグループが新しい主ノードにスイッチオーバーした場合は、アプリケーションリソースグループを手動でスイッチオーバーする必要があります。

   nfs-rg

   アプリケーションリソースグループの名前。

5. アプリケーションリソースグループに SUNW.HAStoragePlus リソースを追加します。

   nodeA# clresource create -g nfs-rg \ -t SUNW.HAStoragePlus \ -p FileSystemMountPoints=/global/mountpoint \ -p AffinityOn=True \ nfs-dg-rs

   create

   リソースを作成します。

   -g

   リソースを追加するリソースグループを指定します。

   -t SUNW.HAStoragePlus

   リソースのタイプに SUNW.HAStoragePlus を指定します。

   -p FileSystemMountPoints=/global/

   ファイルシステムのマウントポイントがグローバルであることを指定します。

   -p AffinityOn=True

   アプリケーションリソースが -p GlobalDevicePaths= で定義されたグローバルデバイスとクラスタファイルシステム向けにアフィニティスイッチオーバーを実行するように指定します。したがって、アプリケーションリソースグループがフェイルオーバーまたはスイッチオーバーすると、関連デバイスグループがスイッチオーバーします。

   nfs-dg-rs

   NFS アプリケーション向けの HAStoragePlus リソースの名前。

   これらの拡張プロパティーについては、SUNW.HAStoragePlus(5) のマニュアルページを参照してください。

6. 論理ホスト名リソースをアプリケーションリソースグループに追加します。

   nodeA# clreslogicalhostname create -g nfs-rg \ lhost-nfsrg-prim

   主クラスタ上のアプリケーションリソースグループの論理ホスト名は lhost-nfsrg-prim です。

7. リソースを有効にし、アプリケーションリソースグループを管理し、アプリケーションリソースグループをオンラインにします。

   1. NFS アプリケーション向けの HAStoragePlus リソースを有効にします。

      nodeA# clresource enable nfs-rs

   2. nodeA でアプリケーションリソースグループをオンラインにします。

      nodeA# clresourcegroup online -e -M -n nodeA nfs-rg

      online

      リソースグループをオンラインにします。

      -e

      関連付けられたリソースを有効にします。

      -M

      リソースグループを管理状態にします。

      -n

      リソースグループをオンラインにするノードを指定します。

      nfs-rg

      リソースグループの名前。

8. アプリケーションリソースグループがオンラインであることを確認します。

   nodeA# clresourcegroup status

   アプリケーションリソースグループの状態フィールドを調べ、複製リソースグループが nodeA と nodeB でオンラインとなっているかどうかを調べます。

次の手順

「二次クラスタで NFS アプリケーションリソースグループを作成する」に進みます。

二次クラスタで NFS アプリケーションリソースグループを作成する

始める前に

手順「主クラスタで NFS アプリケーションリソースグループを作成する」を完了します。

1. nodeC にスーパーユーザーまたは RBAC の承認 solaris.cluster.modify、solaris.cluster.admin、および solaris.cluster.read を提供する役割を使用してアクセスします。

2. SUNW.nfs をリソースタイプとして登録します。

   nodeC# clresourcetype register SUNW.nfs

3. SUNW.HAStoragePlus をリソースタイプとして登録していない場合は、登録します。

   nodeC# clresourcetype register SUNW.HAStoragePlus

4. デバイスグループのアプリケーションリソースグループを作成します。

   nodeC# clresourcegroup create \ -p Pathprefix=/global/etc \ -p Auto_start_on_new_cluster=False \ -p RG_dependencies=devgrp-stor-rg \ nfs-rg

   create

   リソースグループを作成します。

   -p

   リソースグループのプロパティーを指定します。

   Pathprefix=/global/etc

   グループのリソースが管理ファイルを書き込むディレクトリを指定します。

   Auto_start_on_new_cluster=False

   アプリケーションリソースグループが自動的に起動しないように指定します。

   RG_dependencies=devgrp-stor-rg

   アプリケーションリソースグループが依存するリソースグループを指定します。この例では、アプリケーションリソースグループは複製リソースグループに依存しています。

   アプリケーションリソースグループが新しい主ノードにスイッチオーバーすると、複製リソースグループが自動的にスイッチオーバーします。ただし、複製リソースグループが新しい主ノードにスイッチオーバーした場合は、アプリケーションリソースグループを手動でスイッチオーバーする必要があります。

   nfs-rg

   アプリケーションリソースグループの名前。

5. アプリケーションリソースグループに SUNW.HAStoragePlus リソースを追加します。

   nodeC# clresource create -g nfs-rg \ -t SUNW.HAStoragePlus \ -p FileSystemMountPoints=/global/mountpoint \ -p AffinityOn=True \ nfs-dg-rs

   create

   リソースを作成します。

   -g

   リソースを追加するリソースグループを指定します。

   -t SUNW.HAStoragePlus

   リソースのタイプに SUNW.HAStoragePlus を指定します。

   -p

   リソースのプロパティーを指定します。

   FileSystemMountPoints=/global/

   ファイルシステムのマウントポイントがグローバルであることを指定します。

   AffinityOn=True

   アプリケーションリソースが -x GlobalDevicePaths= で定義されたグローバルデバイスとクラスタファイルシステム向けにアフィニティスイッチオーバーを実行するように指定します。したがって、アプリケーションリソースグループがフェイルオーバーまたはスイッチオーバーすると、関連デバイスグループがスイッチオーバーします。

   nfs-dg-rs

   NFS アプリケーション向けの HAStoragePlus リソースの名前。

   これらの拡張プロパティーについては、SUNW.HAStoragePlus(5) のマニュアルページを参照してください。

6. 論理ホスト名リソースをアプリケーションリソースグループに追加します。

   nodeC# clreslogicalhostname create -g nfs-rg \ lhost-nfsrg-sec

   二次クラスタ上のアプリケーションリソースグループの論理ホスト名は lhost-nfsrg-sec です。

7. NFS リソースをアプリケーションリソースグループに追加します。

   nodeC# clresource create -g nfs-rg \ -t SUNW.nfs -p Resource_dependencies=nfs-dg-rs nfs-rg

8. アプリケーションリソースグループが nodeC でオンラインになっていないことを確認します。

   nodeC# clresource disable -n nodeC nfs-rs nodeC# clresource disable -n nodeC nfs-dg-rs nodeC# clresource disable -n nodeC lhost-nfsrg-sec nodeC# clresourcegroup online -n "" nfs-rg

   Auto_start_on_new_cluster=False によって、リソースグループは再起動後もオフラインのままになります。

9. グローバルボリュームが主クラスタにマウントされている場合は、二次クラスタのグローバルボリュームのマウントを解除します。

   nodeC# umount /global/mountpoint

   ボリュームが二次クラスタにマウントされていると、同期が失敗します。

次の手順

「データ複製の有効化例」に進みます。

データ複製の有効化例

この節では、構成例のデータ複製をどのように有効にするかを説明します。この節では、Sun StorageTek Availability Suite ソフトウェアコマンドの sndradm と iiadm を使用します。これらのコマンドについての詳細は、Sun StorageTek Availability のマニュアルを参照してください。

ここで説明する手順は次のとおりです。

• 「主クラスタで複製を有効にする」

• 「 二次クラスタで複製を有効にする」

主クラスタで複製を有効にする

1. nodeA にスーパーユーザーまたは RBAC の承認 solaris.cluster.read を提供する役割を使用してアクセスします。

2. すべてのトランザクションをフラッシュします。

   nodeA# lockfs -a -f

3. 論理ホスト名 lhost-reprg-prim と lhost-reprg-sec がオンラインであることを確認します。

   nodeA# clresourcegroup status nodeC# clresourcegroup status

   リソースグループの状態フィールドを調べます。

4. 主クラスタから二次クラスタへのリモートミラー複製を有効にします。

   この手順によって、主クラスタのマスターボリュームから二次クラスタのマスターボリュームへの複製が有効になります。さらに、vol04 のリモートミラービットマップへの複製も有効になります。

   • 主クラスタと二次クラスタが同期されていない場合は、次のコマンドを実行します。

     • Sun StorEdge Availability Suite ソフトウェアの場合:

       nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -e lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

     • Sun StorageTek Availability Suite ソフトウェアの場合:

       nodeA# /usr/sbin/sndradm -n -e lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

   • 主クラスタと二次クラスタが同期されている場合は、次のコマンドを実行します。

     • Sun StorEdge Availability Suite ソフトウェアの場合:

       nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -E lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

   • Sun StorageTek Availability Suite ソフトウェアの場合:

     nodeA# /usr/sbin/sndradm -n -E lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

5. 自動同期機能を有効にします。

   • Sun StorEdge Availability Suite ソフトウェアの場合:

     nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -a on lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

   • Sun StorageTek Availability Suite ソフトウェアの場合:

     nodeA# /usr/sbin/sndradm -n -a on lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

   この手順で自動同期が有効になります。自動同期のアクティブ状態が on に設定されている場合、システムが再起動されたり障害が発生すると、ボリュームセットは再度同期化されます。

6. クラスタがロギングモードであることを確認します。

   • Sun StorEdge Availability Suite ソフトウェアの場合:

     nodeA# /usr/opt/SUNWesm/sbin/sndradm -P

   • Sun StorageTek Availability Suite ソフトウェアの場合:

     nodeA# /usr/sbin/sndradm -P

   次のような出力が表示されます。

   /dev/vx/rdsk/devgrp/vol01 -> lhost-reprg-sec:/dev/vx/rdsk/devgrp/vol01 autosync: off, max q writes:4194304, max q fbas:16384, mode:sync,ctag: devgrp, state: logging

   ロギングモードでは、状態は logging で、自動同期のアクティブ状態は off です。ディスクのデータボリュームに書き込みが行われると、同じディスクのビットマップファイルが更新されます。

7. ポイントインタイムスナップショットを有効にします。

   • Sun StorEdge Availability Suite ソフトウェアの場合:

     nodeA# /usr/opt/SUNWesm/sbin/iiadm -e ind \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol02 \ /dev/vx/rdsk/devgrp/vol03 nodeA# /usr/opt/SUNWesm/sbin/iiadm -w \ /dev/vx/rdsk/devgrp/vol02

   • Sun StorageTek Availability Suite ソフトウェアの場合:

     nodeA# /usr/sbin/iiadm -e ind \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol02 \ /dev/vx/rdsk/devgrp/vol03 nodeA# /usr/sbin/iiadm -w \ /dev/vx/rdsk/devgrp/vol02

   この手順によって、主クラスタのマスターボリュームが同じクラスタのシャドウボリュームにコピーされるようになります。マスターボリューム、シャドウボリューム、およびポイントインタイムビットマップボリュームは同じデバイスグループに存在する必要があります。この例では、マスターボリュームは vol01、シャドウボリュームは vol02、ポイントインタイムビットマップボリュームは vol03 になります。

8. ポイントインタイムスナップショットをリモートミラーセットに設定します。

   • Sun StorEdge Availability Suite ソフトウェアの場合:

     nodeA# /usr/opt/SUNWesm/sbin/sndradm -I a \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol02 \ /dev/vx/rdsk/devgrp/vol03

   • Sun StorageTek Availability Suite ソフトウェアの場合:

     nodeA# /usr/sbin/sndradm -I a \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol02 \ /dev/vx/rdsk/devgrp/vol03

   この手順によって、ポイントインタイムスナップショットがリモートミラーボリュームセットに関連付けられます。Sun StorageTek Availability Suite ソフトウェアは、リモートミラー複製の前にポイントインタイムスナップショットを必ず取ります。

次の手順

「 二次クラスタで複製を有効にする」に進みます。

二次クラスタで複製を有効にする

始める前に

手順「主クラスタで複製を有効にする」を完了します。

1. スーパーユーザーとして nodeC にアクセスします。

2. すべてのトランザクションをフラッシュします。

   nodeC# lockfs -a -f

3. 主クラスタから二次クラスタへのリモートミラー複製を有効にします。

   • Sun StorEdge Availability Suite ソフトウェアの場合:

     nodeC# /usr/opt/SUNWesm/sbin/sndradm -n -e lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

   • Sun StorageTek Availability Suite ソフトウェアの場合:

     nodeC# /usr/sbin/sndradm -n -e lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

   主クラスタが二次クラスタの存在を認識し、同期を開始します。クラスタのステータスについては、Sun StorEdge Availability Suite のシステムログファイル /var/opt/SUNWesm/ds.log、または Sun StorageTek Availability Suite の /var/adm を参照してください。

4. それぞれのポイントインタイムスナップショットを有効にします。

   • Sun StorEdge Availability Suite ソフトウェアの場合:

     nodeC# /usr/opt/SUNWesm/sbin/iiadm -e ind \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol02 \ /dev/vx/rdsk/devgrp/vol03 nodeC# /usr/opt/SUNWesm/sbin/iiadm -w \ /dev/vx/rdsk/devgrp/vol02

   • Sun StorageTek Availability Suite ソフトウェアの場合:

     nodeC# /usr/sbin/iiadm -e ind \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol02 \ /dev/vx/rdsk/devgrp/vol03 nodeC# /usr/sbin/iiadm -w \ /dev/vx/rdsk/devgrp/vol02

5. ポイントインタイムスナップショットをリモートミラーセットに設定します。

   • Sun StorEdge Availability Suite ソフトウェアの場合:

     nodeC# /usr/opt/SUNWesm/sbin/sndradm -I a \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol02 \ /dev/vx/rdsk/devgrp/vol03

   • Sun StorageTek Availability Suite ソフトウェアの場合:

     nodeC# /usr/sbin/sndradm -I a \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol02 \ /dev/vx/rdsk/devgrp/vol03

次の手順

「データ複製の実行例」に進みます。

データ複製の実行例

この節では、構成例のデータ複製をどのように実行するかを説明します。この節では、Sun StorageTek Availability Suite ソフトウェアコマンドの sndradm と iiadm を使用します。これらのコマンドについての詳細は、Sun StorageTek Availability Suite のマニュアルを参照してください。

ここで説明する手順は次のとおりです。

• 「リモートミラー複製を実行する」

• 「ポイントインタイムスナップショットを実行する」

• 「複製が正しく構成されていることを確認する」

リモートミラー複製を実行する

この手順では、主ディスクのマスターボリュームが二次ディスクのマスターボリュームに複製されます。マスターボリュームは vol01 で、リモートミラービットマップボリュームは vol04 です。

1. スーパーユーザーとして nodeA にアクセスします。

2. クラスタがロギングモードであることを確認します。

   • Sun StorEdge Availability Suite ソフトウェアの場合:

     nodeA# /usr/opt/SUNWesm/sbin/sndradm -P

   • Sun StorageTek Availability Suite ソフトウェアの場合:

     nodeA# /usr/sbin/sndradm -P

   次のような出力が表示されます。

   /dev/vx/rdsk/devgrp/vol01 -> lhost-reprg-sec:/dev/vx/rdsk/devgrp/vol01 autosync: off, max q writes:4194304, max q fbas:16384, mode:sync,ctag: devgrp, state: logging

   ロギングモードでは、状態は logging で、自動同期のアクティブ状態は off です。ディスクのデータボリュームに書き込みが行われると、同じディスクのビットマップファイルが更新されます。

3. すべてのトランザクションをフラッシュします。

   nodeA# lockfs -a -f

4. nodeC で手順 1 から手順 3 を繰り返します。

5. nodeA の マスターボリュームを nodeC のマスターボリュームにコピーします。

   • Sun StorEdge Availability Suite ソフトウェアの場合:

     nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -m lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

   • Sun StorageTek Availability Suite ソフトウェアの場合:

     nodeA# /usr/sbin/sndradm -n -m lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

6. 複製が完了し、ボリュームが同期化されるのを待ちます。

   • Sun StorEdge Availability Suite ソフトウェアの場合:

     nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -w lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

   • Sun StorageTek Availability Suite ソフトウェアの場合:

     nodeA# /usr/sbin/sndradm -n -w lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

7. クラスタが複製モードであることを確認します。

   • Sun StorEdge Availability Suite ソフトウェアの場合:

     nodeA# /usr/opt/SUNWesm/sbin/sndradm -P

   • Sun StorageTek Availability Suite ソフトウェアの場合:

     nodeA# /usr/sbin/sndradm -P

   次のような出力が表示されます。

   /dev/vx/rdsk/devgrp/vol01 -> lhost-reprg-sec:/dev/vx/rdsk/devgrp/vol01 autosync: on, max q writes:4194304, max q fbas:16384, mode:sync,ctag: devgrp, state: replicating

   複製モードでは、状態は replicating で、自動同期のアクティブ状態は on です。主ボリュームに書き込みが行われると、Sun StorageTek Availability Suite ソフトウェアが二次ボリュームを更新します。

次の手順

「ポイントインタイムスナップショットを実行する」に進みます。

ポイントインタイムスナップショットを実行する

この手順では、ポイントインタイムスナップショットを使用して、主クラスタのシャドウボリュームを主クラスタのマスターボリュームに同期させます。マスターボリュームは vol01 、ビットマップボリュームは vol04 、シャドウボリュームは vol02 です。

始める前に

手順「リモートミラー複製を実行する」を完了します。

1. nodeA にスーパーユーザーまたは RBAC の承認 solaris.cluster.modify および solaris.cluster.admin を提供する役割を使用してアクセスします。

2. nodeA で実行されているリソースを無効にします。

   nodeA# clresource disable -n nodeA nfs-rs

3. 主クラスタをロギングモードに変更します。

   • Sun StorEdge Availability Suite ソフトウェアの場合:

     nodeA# /usr/sbin/sndradm -n -l lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

   • Sun StorageTek Availability Suite ソフトウェアの場合:

     nodeA# /usr/sbin/sndradm -n -l lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

   ディスクのデータボリュームに書き込みが行われると、同じディスクのビットマップファイルが更新されます。複製は行われません。

4. 主クラスタのシャドウボリュームを主クラスタのマスターボリュームに同期化させます。

   • Sun StorEdge Availability Suite ソフトウェアの場合:

     nodeA# /usr/opt/SUNWesm/sbin/iiadm -u s /dev/vx/rdsk/devgrp/vol02 nodeA# /usr/opt/SUNWesm/sbin/iiadm -w /dev/vx/rdsk/devgrp/vol02

   • Sun StorageTek Availability Suite ソフトウェアの場合:

     nodeA# /usr/sbin/iiadm -u s /dev/vx/rdsk/devgrp/vol02 nodeA# /usr/sbin/iiadm -w /dev/vx/rdsk/devgrp/vol02

5. 二次クラスタのシャドウボリュームを二次クラスタのマスターボリュームに同期化させます。

   • Sun StorEdge Availability Suite ソフトウェアの場合:

     nodeC# /usr/opt/SUNWesm/sbin/iiadm -u s /dev/vx/rdsk/devgrp/vol02 nodeC# /usr/opt/SUNWesm/sbin/iiadm -w /dev/vx/rdsk/devgrp/vol02

   • Sun StorageTek Availability Suite ソフトウェアの場合:

     nodeC# /usr/sbin/iiadm -u s /dev/vx/rdsk/devgrp/vol02 nodeC# /usr/sbin/iiadm -w /dev/vx/rdsk/devgrp/vol02

6. nodeA でアプリケーションを再起動します。

   nodeA# clresource enable -n nodeA nfs-rs

7. 二次ボリュームを主ボリュームと再同期化させます。

   • Sun StorEdge Availability Suite ソフトウェアの場合:

     nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -u lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

   • Sun StorageTek Availability Suite ソフトウェアの場合:

     nodeA# /usr/sbin/sndradm -n -u lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

次の手順

「複製が正しく構成されていることを確認する」に進みます。

複製が正しく構成されていることを確認する

始める前に

手順「ポイントインタイムスナップショットを実行する」を完了します。

1. nodeA および nodeC にスーパーユーザーまたは RBAC の承認 solaris.cluster.admin を提供する役割を使用してアクセスします。

2. 主クラスタが複製モードで、自動同期機能がオンになっていることを確認します。

   • Sun StorEdge Availability Suite ソフトウェアの場合:

     nodeA# /usr/opt/SUNWesm/sbin/sndradm -P

   • Sun StorageTek Availability Suite ソフトウェアの場合:

     nodeA# /usr/sbin/sndradm -P

   次のような出力が表示されます。

   /dev/vx/rdsk/devgrp/vol01 -> lhost-reprg-sec:/dev/vx/rdsk/devgrp/vol01 autosync: on, max q writes:4194304, max q fbas:16384, mode:sync,ctag: devgrp, state: replicating

   複製モードでは、状態は replicating で、自動同期のアクティブ状態は on です。主ボリュームに書き込みが行われると、Sun StorageTek Availability Suite ソフトウェアが二次ボリュームを更新します。

3. 主クラスタが複製モードでない場合は、複製モードにします。

   • Sun StorEdge Availability Suite ソフトウェアの場合:

     nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -u lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

   • Sun StorageTek Availability Suite ソフトウェアの場合:

     nodeA# /usr/sbin/sndradm -n -u lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

4. クライアントマシンにディレクトリを作成します。

   1. クライアントマシンにスーパーユーザーとしてログインします。

      次のようなプロンプトが表示されます。

      client-machine#

   2. クライアントマシンにディレクトリを作成します。

      client-machine# mkdir /dir

5. ディレクトリを主クラスタのアプリケーションにマウントし、マウントしたディレクトリを表示します。

   1. ディレクトリを主クラスタのアプリケーションにマウントします。

      client-machine# mount -o rw lhost-nfsrg-prim:/global/mountpoint /dir

   2. マウントしたディレクトリを表示します。

      client-machine# ls /dir

6. ディレクトリを二次クラスタのアプリケーションにマウントし、マウントしたディレクトリを表示します。

   1. 主クラスタのアプリケーションからディレクトリのマウントを解除します。

      client-machine# umount /dir

   2. 主クラスタのアプリケーションリソースグループをオフラインにします。

      nodeA# clresource disable -n nodeA nfs-rs nodeA# clresource disable -n nodeA nfs-dg-rs nodeA# clresource disable -n nodeA lhost-nfsrg-prim nodeA# clresourcegroup online -n "" nfs-rg

   3. 主クラスタをロギングモードに変更します。

      • Sun StorEdge Availability Suite ソフトウェアの場合:

        nodeA# /usr/sbin/sndradm -n -l lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

      • Sun StorageTek Availability Suite ソフトウェアの場合:

        nodeA# /usr/sbin/sndradm -n -l lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

      ディスクのデータボリュームに書き込みが行われると、同じディスクのビットマップファイルが更新されます。複製は行われません。

   4. PathPrefix ディレクトリが使用可能であることを確認します。

      nodeC# mount | grep /global/etc

   5. 二次クラスタのアプリケーションリソースグループをオンラインにします。

      nodeC# clresourcegroup online -n nodeC nfs-rg

   6. クライアントマシンにスーパーユーザーとしてアクセスします。

      次のようなプロンプトが表示されます。

      client-machine#

   7. 手順 4 で作成したディレクトリを二次クラスタのアプリケーションにマウントします。

      client-machine# mount -o rw lhost-nfsrg-sec:/global/mountpoint /dir

   8. マウントしたディレクトリを表示します。

      client-machine# ls /dir

7. 手順 5 で表示されたディレクトリが手順 6 で表示されたディレクトリと同じであることを確認します。

8. 主クラスタのアプリケーションをマウントされたディレクトリに戻します。

   1. 二次クラスタのアプリケーションリソースグループをオフラインにします。

      nodeC# clresource disable -n nodeC nfs-rs nodeC# clresource disable -n nodeC nfs-dg-rs nodeC# clresource disable -n nodeC lhost-nfsrg-sec nodeC# clresourcegroup online -n "" nfs-rg

   2. グローバルボリュームを二次クラスタからマウント解除します。

      nodeC# umount /global/mountpoint

   3. 主クラスタのアプリケーションリソースグループをオンラインにします。

      nodeA# clresourcegroup online -n nodeA nfs-rg

   4. 主クラスタを複製モードに変更します。

      • Sun StorEdge Availability Suite ソフトウェアの場合:

        nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -u lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

      • Sun StorageTek Availability Suite ソフトウェアの場合:

        nodeA# /usr/sbin/sndradm -n -u lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

      主ボリュームに書き込みが行われると、Sun StorageTek Availability Suite ソフトウェアが二次ボリュームを更新します。

参照

「フェイルオーバーとスイッチオーバーの管理例」

フェイルオーバーとスイッチオーバーの管理例

この節では、スイッチオーバーの開始方法と、アプリケーションがどのように二次クラスタに転送されるかを説明します。スイッチオーバーまたはフェイルオーバーのあと、DNS エントリを更新します。詳細については、「フェイルオーバーまたはスイッチオーバーの管理ガイドライン」を参照してください。

ここで説明する手順は次のとおりです。

• 「スイッチオーバーを呼び出す」

• 「DNS エントリを更新する」

スイッチオーバーを呼び出す

1. nodeA および nodeC にスーパーユーザーまたは RBAC の承認 solaris.cluster.admin を提供する役割を使用してアクセスします。

2. 主クラスタをロギングモードに変更します。

   • Sun StorEdge Availability Suite ソフトウェアの場合:

     nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -l lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

   • Sun StorageTek Availability Suite ソフトウェアの場合:

     nodeA# /usr/sbin/sndradm -n -l lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

   ディスクのデータボリュームに書き込みが行われると、同じデバイスグループのビットマップボリュームが更新されます。複製は行われません。

3. 主クラスタと二次クラスタがロギングモードで、自動同期がオフであることを確認します。

   1. nodeA で、モードと設定を確認します。

      • Sun StorEdge Availability Suite ソフトウェアの場合:

        nodeA# /usr/opt/SUNWesm/sbin/sndradm -P

      • Sun StorageTek Availability Suite ソフトウェアの場合:

        nodeA# /usr/sbin/sndradm -P

      次のような出力が表示されます。

      /dev/vx/rdsk/devgrp/vol01 -> lhost-reprg-sec:/dev/vx/rdsk/devgrp/vol01 autosync:off, max q writes:4194304,max q fbas:16384,mode:sync,ctag: devgrp, state: logging

   2. nodeC で、モードと設定を確認します。

      • Sun StorEdge Availability Suite ソフトウェアの場合:

        nodeC# /usr/opt/SUNWesm/sbin/sndradm -P

      • Sun StorageTek Availability Suite ソフトウェアの場合:

        nodeC# /usr/sbin/sndradm -P

      次のような出力が表示されます。

      /dev/vx/rdsk/devgrp/vol01 <- lhost-reprg-prim:/dev/vx/rdsk/devgrp/vol01 autosync:off, max q writes:4194304,max q fbas:16384,mode:sync,ctag: devgrp, state: logging

   nodeA と nodeC の状態は logging で、非同期のアクティブ状態は off でなければなりません。

4. 二次クラスタで主クラスタからのテイクオーバーの準備ができていることを確認します。

   nodeC# fsck -y /dev/vx/rdsk/devgrp/vol01

5. 二次クラスタにスイッチオーバーします。

   nodeC# clresourcegroup switch -n nodeC nfs-rg

次の手順

「DNS エントリを更新する」に進みます。

DNS エントリを更新する

DNS がクライアントをクラスタにどのようにマッピングするかについては、図 4–8 を参照してください。

始める前に

手順「スイッチオーバーを呼び出す」を完了します。

1. nsupdate コマンドを開始します。

   詳細は、nsupdate(1M) のマニュアルページを参照してください。

2. 両方のクラスタについて、アプリケーションリソースグループの論理ホスト名とクラスタ IP アドレス間の現在の DNS マッピングを削除します。

   > update delete lhost-nfsrg-prim A > update delete lhost-nfsrg-sec A > update delete ipaddress1rev.in-addr.arpa ttl PTR lhost-nfsrg-prim > update delete ipaddress2rev.in-addr.arpa ttl PTR lhost-nfsrg-sec

   ipaddress1rev

   主クラスタの IP アドレス (逆順) です。

   ipaddress2rev

   二次クラスタの IP アドレス (逆順) です。

   ttl

   秒単位の有効時間です。一般的な値は 3600 になります。

3. 両方のクラスタについて、アプリケーションリソースグループの論理ホスト名とクラスタ IP アドレス間の、新しい DNS マッピングを作成します。

   主論理ホスト名を二次クラスタの IP アドレスにマッピングし、二次論理ホスト名を主クラスタの IP アドレスにマッピングします。

   > update add lhost-nfsrg-prim ttl A ipaddress2fwd > update add lhost-nfsrg-sec ttl A ipaddress1fwd > update add ipaddress2rev.in-addr.arpa ttl PTR lhost-nfsrg-prim > update add ipaddress1rev.in-addr.arpa ttl PTR lhost-nfsrg-sec

   ipaddress2fwd

   二次クラスタの IP アドレス (正順) です。

   ipaddress1fwd

   主クラスタの IP アドレス (正順) です。