この章では、Sun Cluster で利用可能なデータ複製のアプローチについて説明します。クラスタに最適なサービスを提供する複製アプローチの組み合わせを選択するためには、ホストベースとストレージベースのデータ複製を両方とも理解しておく必要があります。
このリリースの Sun Cluster は、次のデータ複製ソフトウェアをサポートしています。
Sun StorageTek Availability Suite 4
Sun StorEdge Availability Suite 3.2.1
Hitachi Truecopy
EMC Symmetrix Remote Data Facility
このマニュアルでは、特に明記していないかぎり、Sun StorageTek Availability Suite ソフトウェアに言及している内容は、Sun StorEdge Availability Suite ソフトウェアにも該当します。
この章で説明する内容は次のとおりです。
「データ複製」とは、主ストレージデバイスからバックアップまたは二次ストレージデバイスへのデータのコピーです。 主デバイスに障害が発生した場合も、二次デバイスからデータを使用できます。このようにして、データ複製を使用すると、クラスタの高可用性と耐災害性を確保できます。
Sun Cluster はデータ複製に対して次のアプローチをサポートしています。
「ホストベースのデータ複製」では、特別なソフトウェアを使用して、地理的に離れたノード間でディスクボリュームをリアルタイムに複製します。リモートミラー複製を使用すると、主ノードのマスターボリュームのデータを、地理的に離れた二次ノードのマスターボリュームに複製できます。リモートミラービットマップは、主ディスク上のマスターボリュームと、二次ディスク上のマスターボリュームの差分を追跡します。
ホストベースのデータ複製は、特別なストレージアレイを必要としないため、比較的安価なデータ複製ソリューションです。ホストベースのデータ複製は、ローカルに接続されたディスクを使用します。ただし、ホストベースのデータ複製はデータの複製にホストのリソースを消費します。また、Oracle RAC などのスケーラブルアプリケーションをサポートしません。構内クラスタ環境でのホストベースのデータ複製の使用法の詳細については、「ホストベースのデータ複製の使用法」を参照してください。2 つ以上のクラスタ間でのホストベースのデータ複製の使用法の詳細については、『Sun Cluster Geographic Edition Data Replication Guide for Sun StorageTek Availability Suite』を参照してください。
「ストレージベースのデータ複製」は、特別なソフトウェアを使用して、データ複製の作業をクラスタノードからストレージデバイスに移動させます。このソフトウェアリロケーションはノードの処理能力を一部解放し、クラスタの要求にサービスを提供します。ストレージベースのデータ複製は、構内クラスタ構成において特に重要になる場合があります。これは、この種類のデータ複製はスケーラブルアプリケーションをサポートし、ホストの負担を軽減するためです。構内クラスタ環境でのストレージベースのデータ複製の使用法の詳細については、「ストレージベースのデータ複製の使用法」を参照してください。2 つ以上のクラスタとプロセスを自動化する Sun Cluster GeoEdition 製品間でのストレージベースの複製の使用法についての詳細は、『Sun Cluster Geographic Edition Data Replication Guide for Hitachi TrueCopy』を参照してください。この章の最後にある「例: Sun StorEdge Availability Suite または Sun StorageTek Availability Suite ソフトウェアを使用したホストベースのデータ複製の構成」では、このようなクラスタ構成の完全な例を示します。
この節では、2 つの場所に設置された構内クラスタにおけるホストベースのデータ複製を説明します。ホストベースのデータ複製を装備した、2 つの場所に設置されたクラスタ構成は次のように定義されます。
2 つの独立した空間。
各空間にはノード 1 個と複数のディスクサブシステムを配置。
空間内のディスクサブシステム間でデータを複製。
両方のホストに接続された 1 個以上のディスクサブシステムを定足数デバイス (一方の空間に配置) として使用
この節の例は一般的な構内クラスタ構成を示したもので、必須構成や推奨構成を示すものではありません。説明を簡単にするため、図や説明は、構内クラスタリングの理解に固有な機能のみを集中的に扱います。たとえば、パブリックネットワークの Ethernet 接続は示してありません。
この構成では、定足数ディスクが失われると、システムは自動的には復旧できなくなります。復旧には Sun のサービスプロバイダによる介入が必要になります。
図 4–1 は、標準的な非構内構成に似ています。構内クラスタでは、マルチモードからシングルモードファイバに切り替えるため、ファイバチャネルスイッチが追加されています。
ストレージベースのデータ複製は、ストレージデバイスにインストールされているソフトウェアを使用して複製を管理します。このようなソフトウェアは、使用するそれぞれのストレージデバイスに固有なものです。ストレージベースのデータ複製を構成する際には、常に、ストレージデバイスに付属するマニュアルを参照してください。
使用するソフトウェアに応じて、ストレージベースのデータ複製を使用して自動または手動いずれかのフェイルオーバーを使用できます。Sun Cluster は、Hitachi TrueCopy および EMC Symmetrix Remote Data Facility ソフトウェアによる複製物の手動および自動フェイルオーバーをサポートしています。
この節では、構内クラスタで使用されるストレージベースのデータ複製を説明します。図 4–2 に、データが 2 つのストレージアレイ間で複製される 2 か所に設置されたクラスタ構成の例を示します。この例では、第一の場所に主ストレージアレイがあり、これが両方の場所のノードにデータを提供します。また主ストレージアレイは、複製するデータを二次ストレージアレイに提供します。
図 4–2 に示すように、複製された側ではないボリューム上に定足数デバイスがあります。複製されたボリュームを定足数デバイスとして使用することはできません。
使用されるアプリケーションの種類に応じて、Sun Cluster 環境では、ストレージベースのデータ複製を同期または非同期に実行できます。
データの整合性を保証するために、マルチパスと適切な RAID パッケージを使用します。次のリストには、ストレージベースのデータ複製を使用する構内クラスタ構成を実装するための考慮事項が含まれています。
ノードからノードヘの距離は、Sun Cluster Fibre Channel とインターコネクトインフラストラクチャーにより制限されます。現在の制限とサポートされる技術の詳細については、Sun のサービスプロバイダにお問い合わせください。
複製されたボリュームを、定足数デバイスとして構成しないでください。共有の複製されていないボリュームにある定足数デバイスを見つけるか、定足数サーバーを使用します。
データの主コピーのみがクラスタノードに認識されるようにします。このようにしないと、ボリュームマネージャーはデータの主コピーと二次コピーの両方に同時にアクセスしようとする場合があります。
EMC Symmetrix Remote Data Facility と Hitachi TrueCopy では、ユーザーが複製されたデバイスのグループを定義できます。複製されたデバイスグループと Sun Cluster グローバルデバイスグループには同じ名前を使用して、これらが 1 つのユニットとしてノード間を移動できるようにします。
データコピーの可視性の制御に関しては、ご使用のストレージアレイに付属するマニュアルを参照してください。
特定のアプリケーション固有のデータは、非同期データ複製には適さない場合があります。アプリケーションの動作に関する知識を活用して、ストレージデバイス間でアプリケーション固有のデータを複製する最善の方法を決定します。
クラスタを自動フェイルオーバー用に構成する場合は、同期複製を使用します。
複製されたボリュームの自動フェイルオーバー用にクラスタを構成する手順については、「ストレージベースの複製されたデバイスの管理」を参照してください。
Oracle Real Application Clusters (RAC) はサポートされません。
CVM および Sun Cluster ソフトウェア用 Solaris ボリュームマネージャーはサポートされません。
すべての構内クラスタと同じように、ストレージベースのデータ複製を使用するクラスタは、通常、1 つの障害が発生した場合はユーザーの操作は必要ありません。ただし、( 図 4–2 に示すように) 手動フェイルオーバーを使用し、主ストレージデバイスを保持する空間が失われた場合、2 ノードクラスタでは問題が発生します。残ったノードは定足数デバイスを予約できず、またクラスタメンバーとして起動できません。このような状況では、クラスタには次の手動操作が必要になります。
クラスタメンバーとして起動するよう、Sun のサービスプロバイダが残りのノードを再構成する必要があります。
ユーザーまたは Sun のサービスプロバイダが、二次ストレージデバイスの複製されてない方のボリュームを定足数デバイスとして構成する必要があります。
二次ストレージデバイスを主ストレージとして使用できるよう、ユーザーまたは Sun のサービスプロバイダが残りのノードを構成する必要があります。このような再構成には、ボリュームマネージャーボリュームの再構築、データの復元、ストレージボリュームとアプリケーションの関連付けの変更が含まれます。
ストレージベースのデータ複製用の Hitachi TrueCopy ソフトウェアを使用するデバイスグループを設定する場合、次のプラクティスに従ってください。
同期複製を使用して、主サイトに障害が発生したときにデータの損失を防ぎます。
Sun Cluster グローバルデバイスグループとhorcm 構成ファイルで定義された TrueCopy 複製グループの間に 1 対 1 の関係が存在するようにしてください。これにより、両方のグループが 1 つの単位としてノードからノードへ移動することができます。
同一の複製されたデバイスグループ内にグローバルファイルシステムボリュームとフェイルオーバーファイルシステムボリュームを混在させることはできません。
すべての RAID マネージャーインスタンスが常に起動され実行中であるべきです。
EMC Symmetrix Remote Data Facility を使用する場合は、静的デバイスではなく、動的デバイスを使用します。静的デバイスでは主複製を変更するのに数分かかり、フェイルオーバー時間に影響を与えることがあります。
この節では、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 が使用するリモートミラー複製方式とポイントインタイムスナップショット方式について説明します。このソフトウェアは、 sndradm(1RPC) と iiadm(1II) コマンドを使用してデータを複製します。
図 4–3 は、リモートミラー複製を示しています。主ディスクのマスターボリュームのデータは、TCP/IP 接続を経由して二次ディスクのマスターボリュームに複製されます。リモートミラービットマップは、主ディスク上のマスターボリュームと、二次ディスク上のマスターボリュームの差分を追跡します。
リモートミラー複製は、リアルタイムに同期で実行することも非同期で実行することもできます。各クラスタの各ボリュームセットはそれぞれ、同期複製または非同期複製に構成できます。
図 4–4 は、ポイントインタイムスナップショットを示しています。各ディスクのマスターボリュームのデータは、同じディスクのシャドウボリュームにコピーされます。ポイントインタイムピットマップは、マスターボリュームとシャドウボリューム間の違いを追跡調査します。データがシャドウボリュームにコピーされると、ポイントインタイムビットマップはリセットされます。
図 4–5 に、この構成例でミラー複製とポイントインタイムスナップショットがどのように使用されているかを示します。
この節では、クラスタ間のデータ複製の構成ガイドラインを提供します。また、複製リソースグループとアプリケーションリソースグループの構成のコツも紹介します。これらのガイドラインは、クラスタのデータ複製を構成する際に使用してください。
この節では、次の項目について説明します。
複製リソースグループは、Sun StorageTek Availability Suite ソフトウェアが制御するデバイスグループと論理ホスト名リソースを相互に関連付けます。複製リソースグループには、次の特徴があります。
フェイルオーバーリソースグループである
フェイルオーバーリソースは、常に単一のノード上で実行されます。フェイルオーバーが発生すると、フェイルオーバーリソースがフェイルオーバーに加わります。
論理ホスト名は、主クラスタがホストでなければなりません。フェイルオーバーまたはスイッチオーバーの後は、二次クラスタが論理ホスト名のホストになる必要があります。ドメインネームシステム (DNS) は、論理ホスト名とクラスタを関連付けるために使用されます。
HAStoragePlus リソースを持つ
HAStoragePlus リソースは、複製リソースグループがスイッチオーバーまたはフェイルオーバーしたときに、デバイスグループをスイッチオーバーします。Sun Cluster ソフトウェアはまた、デバイスグループがスイッチオーバーしたときに、複製リソースグループをスイッチオーバーします。このように複製リソースグループとデバイスグループは常に結び付き、同じノードから制御されます。
HAStoragePlus リソース内に次の拡張プロパティを定義する必要があります。
AffinityOn property = True。この拡張プロパティは、複製リソースグループがスイッチオーバーまたはフェイルオーバーしたときに、デバイスグループをスイッチオーバーまたはフェイルオーバーします。この機能はアフィニティースイッチオーバーと呼ばれます。
ZPoolsSearchDir. この拡張プロパティーは、ZFS ファイルシステムを使用するために必要です。
HAStoragePlus については、SUNW.HAStoragePlus(5) のマニュアルページを参照してください。
結び付いているデバイスグループに -stor-rg を付けた名前になる
たとえば、devgrp-stor-rg などです。
主クラスタと二次クラスタでオンラインになる
高可用性を実現するためには、アプリケーションはアプリケーションリソースグループのリソースとして管理される必要があります。アプリケーションリソースグループは、フェイルオーバーアプリケーションまたはスケーラブルアプリケーション向けに構成できます。
主クラスタ上に構成したアプリケーションリソースとアプリケーションリソースグループは、二次クラスタ上でも構成される必要があります。また、アプリケーションリソースがアクセスするデータは、二次クラスタに複製する必要があります。
この節では、次のアプリケーションリソースグループを構成するためのガイドラインを紹介します。
フェイルオーバーアプリケーションでは、1 つのアプリケーションが 1 度に 1 ノード上で動作します。ノードで障害が発生すると、アプリケーションは同じクラスタ内の別のノードにフェイルオーバーします。フェイルオーバーアプリケーション向けリソースグループは、以下の特徴を持っていなければなりません。
アプリケーションリソースグループがスイッチオーバーまたはフェイルオーバーされた場合、 HAStoragePlus リソースにデバイスグループをスイッチオーバーさせる
デバイスグループは、複製リソースグループとアプリケーションリソースグループに結び付けられています。したがって、アプリケーションリソースグループがスイッチオーバーすると、デバイスグループと複製リソースグループもスイッチオーバーします。アプリケーションリソースグループ、複製リソースグループおよびデバイスグループは、同じノードによって制御されます。
ただし、デバイスグループや複製リソースグループがスイッチオーバーまたはフェイルオーバーしても、アプリケーションリソースグループはスイッチオーバーやフェイルオーバーを行いません。
アプリケーションデータがグローバルマウントされている場合は、アプリケーションリソースグループに HAStoragePlus リソースを必ず入れなければならないわけではありませんが、入れることをお勧めします。
アプリケーションデータがローカルマウントされている場合は、アプリケーションリソースグループに HAStoragePlus リソースを必ず入れなければなりません。
HAStoragePlus リソースがないと、アプリケーションリソースグループがスイッチオーバーまたはフェイルオーバーしても、複製リソースグループとデバイスグループのスイッチオーバーやフェイルオーバーは行われません。スイッチオーバーやフェイルオーバーの後は、アプリケーションリソースグループ、複製リソースグループおよびデバイスグループは同じノードからは制御されません。
HAStoragePlus については、SUNW.HAStoragePlus(5) のマニュアルページを参照してください。
主クラスタでオンライン、二次クラスタでオフラインとなる
二次クラスタが主クラスタをテイクオーバーした場合は、二次クラスタ上のアプリケーションリソースグループをオンラインにします。
図 4–6 フェイルオーバーアプリケーションでのアプリケーションリソースグループと複製リソースグループの構成を示す図
スケーラブルアプリケーションでは、アプリケーションは複数のノードで実行されて、1つの論理サービスを作成します。スケーラブルアプリケーションを実行しているノードで障害が発生しても、フェイルオーバーは起こりません。アプリケーションは別のノードで引き続き実行されます。
スケーラブルアプリケーションをアプリケーションリソースグループのリソースとして管理している場合は、アプリケーションリソースグループをデバイスグループと結び付ける必要はありません。したがって、アプリケーションリソースグループ向けに HAStoragePlus リソースを作成する必要はありません。
スケーラブルアプリケーション向けリソースグループは、以下の特徴を持っていなければなりません。
共有アドレスは、受信データを配信するためにスケーラブルアプリケーションを実行するノードで使用されます。
主クラスタでオンライン、二次クラスタでオフラインとなる
図 4–7 スケーラブルアプリケーションでのリソースグループの構成を示す図
主クラスタで障害が発生した場合、できるだけ速やかにアプリケーションを二次クラスタにスイッチオーバーする必要があります。二次クラスタがテイクオーバーできるようにするには、DNS を更新する必要があります。
DNS は、クライアントをアプリケーションの論理ホスト名に関連付けます。フェイルオーバーまたはスイッチオーバーの後、主クラスタへの DNS マッピングを削除し、二次クラスタへの DNS マッピングを作成します。図 4–8 DNS がどのようにクライアントをクラスタにマッピングするかを示す図
DNS を更新するには、nsupdate コマンドを使用します。詳細は、nsupdate(1M) のマニュアルページを参照してください。フェイルオーバーやスイッチオーバーの管理方法の例については、「フェイルオーバーとスイッチオーバーの管理例」を参照してください。
修復後は、 主クラスタをオンラインに戻せます。元の主クラスタにスイッチバックするには、次の手順を実行します。
主クラスタと二次クラスタを同期させ、主ボリュームが最新のものであることを確認します。
クライアントが主クラスタのアプリケーションにアクセスできるように、DNS を更新します。
表 4–1 に、Sun StorageTek Availability Suite ソフトウェアを使用して NFS アプリケーション向けにどのようにデータ複製を構成するかを示すこの例での作業を示します。
表 4–1 作業マップ: データ複製の構成例
作業 |
参照先 |
---|---|
1. クラスタを接続およびインストールする。 | |
2. 主クラスタと二次クラスタで、デバイスグループ、NFS アプリケーション用のファイルシステム、およびリソースグループを構成する。 | |
3. 主クラスタと二次クラスタでデータ複製を有効にする。 | |
4. データ複製を実行する。 | |
5. データ複製の構成を確認する。 |
図 4–9 に構成例で使用するクラスタ構成を示します。構成例の二次クラスタにはノードが 1 つ含まれていますが、これ以外のクラスタ構成も使用できます。
表 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 2/08 ソフトウェア インストールについては、『Sun Cluster ソフトウェアのインストール (Solaris OS 版)』を参照してください。 |
ボリューム管理ソフトウェア |
Solstice DiskSuite または Solaris ボリュームマネージャー ソフトウェアまたは VERITAS Volume Manager (VxVM) ソフトウェア すべてのノードで、同じバージョンのボリューム管理ソフトウェアを使用する。 インストールについては、『Sun Cluster ソフトウェアのインストール (Solaris OS 版)』の第 4 章「Solaris Volume Manager ソフトウェアの構成」および『Sun Cluster ソフトウェアのインストール (Solaris OS 版)』の第 5 章「VERITAS Volume Manager をインストールして構成する」を参照してください。 |
Sun StorageTek Availability Suite ソフトウェア |
ソフトウェアのインストール方法については、使用しているリリースの Sun StorageTek Availability Suite または Sun StorageTek Availability Suite ソフトウェアのインストールマニュアルを参照してください。
|
Sun StorageTek Availability Suite ソフトウェアパッチ |
最新のパッチについては、http://www.sunsolve.com を参照 |
この節では、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 Volume Manager ソフトウェアの構成」を参照してください。
デバイスグループで作成済みのボリュームを下図に示します。
この手順で定義されたボリュームに、シリンダ 0 などのディスクラベルのプライベート領域を含めてはなりません。VxVM ソフトウェアは、この制限を自動管理します。
次の作業を完成していることを確認してください。
次の節のガイドラインと要件を確認します。
「クラスタの接続とインストール」で説明されているように、主クラスタおよび二次クラスタを設定します。
nodeA にスーパーユーザーまたは RBAC の承認 solaris.cluster.modify を提供する役割を使用してアクセスします。
nodeA は、主クラスタの最初のノードです。どのノードが nodeA であるかを確認するには、 図 4–9 を参照してください。
nodeA でボリューム 1 vol01 からボリューム 4 vol04 を含むディスクグループを作成します。
VxVM ソフトウェアを使用したディスクグループの構成については、『Sun Cluster ソフトウェアのインストール (Solaris OS 版)』の第 5 章「VERITAS Volume Manager をインストールして構成する」を参照してください。
ディスクグループを構成して、デバイスグループを作成します。
nodeA# cldevicegroup create -t vxvm -n nodeA nodeB devgrp |
デバイスグループは devgrp と呼ばれます。
デバイスグループのファイルシステムを作成します。
nodeA# newfs /dev/vx/rdsk/devgrp/vol01 < /dev/null nodeA# newfs /dev/vx/rdsk/devgrp/vol02 < /dev/null |
vol03 と vol04 は raw ボリュームとして使用されるため、ファイルシステムは必要ありません。
「二次クラスタでデバイスグループを構成する」に進みます。
手順「主クラスタでデバイスグループを構成する」を完了します。
nodeC にスーパーユーザーまたは RBAC の承認 solaris.cluster.modify を提供する役割を使用してアクセスします。
nodeC でボリューム 1 vol01 からボリューム 4 vol04 までの 4 つのボリュームを含む ディスクグループを作成します。
ディスクグループを構成して、デバイスグループを作成します。
nodeC# cldevicegroup create -t vxvm -n nodeC devgrp |
デバイスグループは devgrp という名前です。
デバイスグループのファイルシステムを作成します。
nodeC# newfs /dev/vx/rdsk/devgrp/vol01 < /dev/null nodeC# newfs /dev/vx/rdsk/devgrp/vol02 < /dev/null |
vol03 と vol04 は raw ボリュームとして使用されるため、ファイルシステムは必要ありません。
「主クラスタのファイルシステムを NFS アプリケーション向けに構成する」に進みます。
手順「二次クラスタでデバイスグループを構成する」を完了します。
nodeA および nodeB で、スーパーユーザーまたは RBAC の承認 solaris.cluster.admin を提供する役割になります。
nodeA と nodeB で、NFS ファイルシステム向けのマウントポイントディレクトリを作成します。
次に例を示します。
nodeA# mkdir /global/mountpoint |
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 を参照してください。
nodeA で、Sun Cluster HA for NFS データサービスが使用するファイルのシステム情報向けのボリュームを作成します。
nodeA# vxassist -g devgrp make vol05 120m disk1 |
ボリューム 5 vol05 には Sun Cluster HA for NFS データサービスが使用するファイルシステム情報が含まれています。
nodeA で、デバイスグループと Sun Cluster ソフトウェアを再同期化します。
nodeA# cldevicegroup sync devgrp |
nodeA で、vol05 用のファイルシステムを作成します。
nodeA# newfs /dev/vx/rdsk/devgrp/vol05 |
nodeA と nodeB で、vol05 のマウントポイントを作成します。
次の例では、マウントポイント /global/etc を作成しています。
nodeA# mkdir /global/etc |
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 |
nodeA に vol05 をマウントします。
nodeA# mount /global/etc |
vol05 がリモートシステムからアクセスできるようにします。
「二次クラスタのファイルシステムを NFS アプリケーション向けに構成する」に進みます。
手順「主クラスタのファイルシステムを NFS アプリケーション向けに構成する」を完了します。
nodeC で、スーパーユーザーまたは RBAC の承認 solaris.cluster.admin を提供する役割になります。
nodeC で、NFS ファイルシステム向けのマウントポイントディレクトリを作成します。
次に例を示します。
nodeC# mkdir /global/mountpoint |
nodeC で、マウントポイントに自動でマウントされるようにマスターボリュームを構成します。
nodeC の /etc/vfstab ファイルに以下のテキストを追加するか、既存のテキストと置き換えます。テキストは 1 行で記述してください。
/dev/vx/dsk/devgrp/vol01 /dev/vx/rdsk/devgrp/vol01 \ /global/mountpoint ufs 3 no global,logging |
nodeC で、Sun Cluster HA for NFS データサービスが使用するファイルのシステム情報向けのボリュームを作成します。
nodeC# vxassist -g devgrp make vol05 120m disk1 |
ボリューム 5 vol05 には Sun Cluster HA for NFS データサービスが使用するファイルシステム情報が含まれています。
nodeC で、デバイスグループと Sun Cluster ソフトウェアを再同期化します。
nodeC# cldevicegroup sync devgrp |
nodeC で、vol05 用のファイルシステムを作成します。
nodeC# newfs /dev/vx/rdsk/devgrp/vol05 |
nodeC で、vol05 用のマウントポイントを作成します。
次の例では、マウントポイント /global/etc を作成しています。
nodeC# mkdir /global/etc |
nodeC で、vol05 がマウントポイントで自動的にマウントされるよう構成します。
nodeC の /etc/vfstab ファイルに以下のテキストを追加するか、既存のテキストと置き換えます。テキストは 1 行で記述してください。
/dev/vx/dsk/devgrp/vol05 /dev/vx/rdsk/devgrp/vol05 \ /global/etc ufs 3 yes global,logging |
nodeC に vol05 をマウントします。
nodeC# mount /global/etc |
vol05 がリモートシステムからアクセスできるようにします。
「主クラスタで複製リソースグループを作成する」に進みます。
手順「二次クラスタのファイルシステムを NFS アプリケーション向けに構成する」を完了します。
nodeA にスーパーユーザーまたは RBAC の承認 solaris.cluster.modify、solaris.cluster.admin、および solaris.cluster.read を提供する役割を使用してアクセスします。
SUNW.HAStoragePlus というリソースタイプを登録します。
nodeA# clresourcetype register SUNW.HAStoragePlus |
デバイスグループの複製リソースグループを作成します。
nodeA# clresourcegroup create -n nodeA,nodeB devgrp-stor-rg |
クラスタノード nodeA および nodeB が複製リソースグループをマスターできることを指定します。
複製リソースグループの名前。この名前で、devgrp はデバイスグループの名前を指定します。
複製リソースグループに SUNW.HAStoragePlus リソースを追加します。
nodeA# clresource create -g devgrp-stor-rg -t SUNW.HAStoragePlus \ -p GlobalDevicePaths=devgrp \ -p AffinityOn=True \ devgrp-stor |
リソースを追加するリソースグループを指定します。
Sun StorageTek Availability Suite ソフトウェアが依存する拡張プロパティーを指定します。
SUNW.HAStoragePlus リソースが、-x GlobalDevicePaths= で定義されたグローバルデバイスおよびクラスタファイルシステムに対して、アフィニティースイッチオーバーを実行することを指定します。したがって、複製リソースグループがフェイルオーバーまたはスイッチオーバーすると、関連デバイスグループがスイッチオーバーします。
これらの拡張プロパティーについては、SUNW.HAStoragePlus(5) のマニュアルページを参照してください。
論理ホスト名リソースを複製リソースグループに追加します。
nodeA# clreslogicalhostname create -g devgrp-stor-rg lhost-reprg-prim |
主クラスタ上の複製リソースグループの論理ホスト名は lhost-reprg-prim です。
リソースを有効にし、リソースグループを管理し、リソースグループをオンラインにします。
nodeA# clresourcegroup online -e -M -n nodeA devgrp-stor-rg |
関連付けられたリソースを有効にします。
リソースグループを管理状態にします。
リソースグループをオンラインにするノードを指定します。
リソースグループがオンラインであることを確認します。
nodeA# clresourcegroup status devgrp-stor-rg |
リソースグループの状態フィールドを調べ、複製リソースグループが nodeA でオンラインとなっていることを確認します。
「二次クラスタで複製リソースグループを作成する」に進みます。
手順「主クラスタで複製リソースグループを作成する」を完了します。
nodeC にスーパーユーザーまたは RBAC の承認 solaris.cluster.modify、solaris.cluster.admin、および solaris.cluster.read を提供する役割を使用してアクセスします。
SUNW.HAStoragePlus というリソースタイプを登録します。
nodeC# clresourcetype register SUNW.HAStoragePlus |
デバイスグループの複製リソースグループを作成します。
nodeC# clresourcegroup create -n nodeC devgrp-stor-rg |
リソースグループを作成します。
リソースグループのノードリストを指定します。
デバイスグループの名前。
複製リソースグループの名前。
複製リソースグループに SUNW.HAStoragePlus リソースを追加します。
nodeC# clresource create \ -t SUNW.HAStoragePlus \ -p GlobalDevicePaths=devgrp \ -p AffinityOn=True \ devgrp-stor |
リソースを作成します。
リソースタイプを指定します。
Sun StorageTek Availability Suite ソフトウェアが依存する拡張プロパティーを指定します。
SUNW.HAStoragePlus リソースが、-x GlobalDevicePaths= で定義されたグローバルデバイスおよびクラスタファイルシステムに対して、アフィニティースイッチオーバーを実行することを指定します。したがって、複製リソースグループがフェイルオーバーまたはスイッチオーバーすると、関連デバイスグループがスイッチオーバーします。
複製リソースグループの HAStoragePlus リソース
これらの拡張プロパティーについては、SUNW.HAStoragePlus(5) のマニュアルページを参照してください。
論理ホスト名リソースを複製リソースグループに追加します。
nodeC# clreslogicalhostname create -g devgrp-stor-rg lhost-reprg-sec |
主クラスタ上の複製リソースグループの論理ホスト名は lhost-reprg-sec です。
リソースを有効にし、リソースグループを管理し、リソースグループをオンラインにします。
nodeC# clresourcegroup online -e -M -n nodeC devgrp-stor-rg |
オンラインにします。
関連付けられたリソースを有効にします。
リソースグループを管理状態にします。
リソースグループをオンラインにするノードを指定します。
リソースグループがオンラインであることを確認します。
nodeC# clresourcegroup status devgrp-stor-rg |
リソースグループの状態フィールドを調べ、複製リソースグループが nodeC でオンラインとなっていることを確認します。
「主クラスタで NFS アプリケーションリソースグループを作成する」に進みます。
この手順では、アプリケーションリソースグループを NFS に対して作成する方法を説明します。この手順はこのアプリケーションに固有で、別の種類のアプリケーションには使用できません。
手順「二次クラスタで複製リソースグループを作成する」を完了します。
nodeA にスーパーユーザーまたは RBAC の承認 solaris.cluster.modify、solaris.cluster.admin、および solaris.cluster.read を提供する役割を使用してアクセスします。
SUNW.nfs をリソースタイプとして登録します。
nodeA# clresourcetype register SUNW.nfs |
SUNW.HAStoragePlus をリソースタイプとして登録していない場合は、登録します。
nodeA# clresourcetype register SUNW.HAStoragePlus |
デバイスグループ devgrp のアプリケーションリソースグループを作成します。
nodeA# clresourcegroup create \ -p Pathprefix=/global/etc \ -p Auto_start_on_new_cluster=False \ -p RG_dependencies=devgrp-stor-rg \ nfs-rg |
グループのリソースが管理ファイルを書き込むディレクトリを指定します。
アプリケーションリソースグループが自動的に起動しないように指定します。
アプリケーションリソースグループが依存するリソースグループを指定します。この例では、アプリケーションリソースグループは複製リソースグループ devgrp-stor-rg に依存しています。
アプリケーションリソースグループが新しい主ノードにスイッチオーバーすると、複製リソースグループが自動的にスイッチオーバーします。ただし、複製リソースグループが新しい主ノードにスイッチオーバーした場合は、アプリケーションリソースグループを手動でスイッチオーバーする必要があります。
アプリケーションリソースグループの名前。
アプリケーションリソースグループに SUNW.HAStoragePlus リソースを追加します。
nodeA# clresource create -g nfs-rg \ -t SUNW.HAStoragePlus \ -p FileSystemMountPoints=/global/mountpoint \ -p AffinityOn=True \ nfs-dg-rs |
リソースを作成します。
リソースを追加するリソースグループを指定します。
リソースのタイプに SUNW.HAStoragePlus を指定します。
ファイルシステムのマウントポイントがグローバルであることを指定します。
アプリケーションリソースが -p GlobalDevicePaths= で定義されたグローバルデバイスとクラスタファイルシステム向けにアフィニティスイッチオーバーを実行するように指定します。したがって、アプリケーションリソースグループがフェイルオーバーまたはスイッチオーバーすると、関連デバイスグループがスイッチオーバーします。
NFS アプリケーション向けの HAStoragePlus リソースの名前。
これらの拡張プロパティーについては、SUNW.HAStoragePlus(5) のマニュアルページを参照してください。
論理ホスト名リソースをアプリケーションリソースグループに追加します。
nodeA# clreslogicalhostname create -g nfs-rg \ lhost-nfsrg-prim |
主クラスタ上のアプリケーションリソースグループの論理ホスト名は lhost-nfsrg-prim です。
リソースを有効にし、アプリケーションリソースグループを管理し、アプリケーションリソースグループをオンラインにします。
アプリケーションリソースグループがオンラインであることを確認します。
nodeA# clresourcegroup status |
アプリケーションリソースグループの状態フィールドを調べ、複製リソースグループが nodeA と nodeB でオンラインとなっているかどうかを調べます。
「二次クラスタで NFS アプリケーションリソースグループを作成する」に進みます。
手順「主クラスタで NFS アプリケーションリソースグループを作成する」を完了します。
nodeC にスーパーユーザーまたは RBAC の承認 solaris.cluster.modify、solaris.cluster.admin、および solaris.cluster.read を提供する役割を使用してアクセスします。
SUNW.nfs をリソースタイプとして登録します。
nodeC# clresourcetype register SUNW.nfs |
SUNW.HAStoragePlus をリソースタイプとして登録していない場合は、登録します。
nodeC# clresourcetype register SUNW.HAStoragePlus |
デバイスグループのアプリケーションリソースグループを作成します。
nodeC# clresourcegroup create \ -p Pathprefix=/global/etc \ -p Auto_start_on_new_cluster=False \ -p RG_dependencies=devgrp-stor-rg \ nfs-rg |
リソースグループを作成します。
リソースグループのプロパティーを指定します。
グループのリソースが管理ファイルを書き込むディレクトリを指定します。
アプリケーションリソースグループが自動的に起動しないように指定します。
アプリケーションリソースグループが依存するリソースグループを指定します。この例では、アプリケーションリソースグループは複製リソースグループに依存しています。
アプリケーションリソースグループが新しい主ノードにスイッチオーバーすると、複製リソースグループが自動的にスイッチオーバーします。ただし、複製リソースグループが新しい主ノードにスイッチオーバーした場合は、アプリケーションリソースグループを手動でスイッチオーバーする必要があります。
アプリケーションリソースグループの名前。
アプリケーションリソースグループに SUNW.HAStoragePlus リソースを追加します。
nodeC# clresource create -g nfs-rg \ -t SUNW.HAStoragePlus \ -p FileSystemMountPoints=/global/mountpoint \ -p AffinityOn=True \ nfs-dg-rs |
リソースを作成します。
リソースを追加するリソースグループを指定します。
リソースのタイプに SUNW.HAStoragePlus を指定します。
リソースのプロパティーを指定します。
ファイルシステムのマウントポイントがグローバルであることを指定します。
アプリケーションリソースが -x GlobalDevicePaths= で定義されたグローバルデバイスとクラスタファイルシステム向けにアフィニティスイッチオーバーを実行するように指定します。したがって、アプリケーションリソースグループがフェイルオーバーまたはスイッチオーバーすると、関連デバイスグループがスイッチオーバーします。
NFS アプリケーション向けの HAStoragePlus リソースの名前。
これらの拡張プロパティーについては、SUNW.HAStoragePlus(5) のマニュアルページを参照してください。
論理ホスト名リソースをアプリケーションリソースグループに追加します。
nodeC# clreslogicalhostname create -g nfs-rg \ lhost-nfsrg-sec |
二次クラスタ上のアプリケーションリソースグループの論理ホスト名は lhost-nfsrg-sec です。
NFS リソースをアプリケーションリソースグループに追加します。
nodeC# clresource create -g nfs-rg \ -t SUNW.nfs -p Resource_dependencies=nfs-dg-rs nfs-rg |
アプリケーションリソースグループが 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 によって、リソースグループは再起動後もオフラインのままになります。
グローバルボリュームが主クラスタにマウントされている場合は、二次クラスタのグローバルボリュームのマウントを解除します。
nodeC# umount /global/mountpoint |
ボリュームが二次クラスタにマウントされていると、同期が失敗します。
「データ複製の有効化例」に進みます。
この節では、構成例のデータ複製をどのように有効にするかを説明します。この節では、Sun StorageTek Availability Suite ソフトウェアコマンドの sndradm と iiadm を使用します。これらのコマンドの詳細は、Sun StorageTek Availability のマニュアルを参照してください。
ここでは、次の手順について説明します。
nodeA にスーパーユーザーまたは RBAC の承認 solaris.cluster.read を提供する役割を使用してアクセスします。
すべてのトランザクションをフラッシュします。
nodeA# lockfs -a -f |
論理ホスト名 lhost-reprg-prim と lhost-reprg-sec がオンラインであることを確認します。
nodeA# clresourcegroup status nodeC# clresourcegroup status |
リソースグループの状態フィールドを調べます。
主クラスタから二次クラスタへのリモートミラー複製を有効にします。
この手順によって、主クラスタのマスターボリュームから二次クラスタのマスターボリュームへの複製が有効になります。さらに、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 |
自動同期機能を有効にします。
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 に設定されている場合、システムが再起動されたり障害が発生すると、ボリュームセットは再度同期化されます。
クラスタがロギングモードであることを確認します。
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 です。ディスクのデータボリュームに書き込みが行われると、同じディスクのビットマップファイルが更新されます。
ポイントインタイムスナップショットを有効にします。
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 になります。
ポイントインタイムスナップショットをリモートミラーセットに設定します。
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 ソフトウェアは、リモートミラー複製の前にポイントインタイムスナップショットを必ず取ります。
「 二次クラスタで複製を有効にする」に進みます。
手順「主クラスタで複製を有効にする」を完了します。
スーパーユーザーとして nodeC にアクセスします。
すべてのトランザクションをフラッシュします。
nodeC# lockfs -a -f |
主クラスタから二次クラスタへのリモートミラー複製を有効にします。
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 を参照してください。
それぞれのポイントインタイムスナップショットを有効にします。
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 |
ポイントインタイムスナップショットをリモートミラーセットに設定します。
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 です。
スーパーユーザーとして 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 |
ロギングモードでは、状態は logging で、自動同期のアクティブ状態は off です。ディスクのデータボリュームに書き込みが行われると、同じディスクのビットマップファイルが更新されます。
すべてのトランザクションをフラッシュします。
nodeA# lockfs -a -f |
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 |
複製が完了し、ボリュームが同期化されるのを待ちます。
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 |
クラスタが複製モードであることを確認します。
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 です。
手順「リモートミラー複製を実行する」を完了します。
nodeA にスーパーユーザーまたは RBAC の承認 solaris.cluster.modify および solaris.cluster.admin を提供する役割を使用してアクセスします。
nodeA で実行されているリソースを無効にします。
nodeA# clresource disable -n nodeA nfs-rs |
主クラスタをロギングモードに変更します。
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 |
ディスクのデータボリュームに書き込みが行われると、同じディスクのビットマップファイルが更新されます。複製は行われません。
主クラスタのシャドウボリュームを主クラスタのマスターボリュームに同期化させます。
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 |
二次クラスタのシャドウボリュームを二次クラスタのマスターボリュームに同期化させます。
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 |
nodeA でアプリケーションを再起動します。
nodeA# clresource enable -n nodeA nfs-rs |
二次ボリュームを主ボリュームと再同期化させます。
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 |
「複製が正しく構成されていることを確認する」に進みます。
手順「ポイントインタイムスナップショットを実行する」を完了します。
nodeA および nodeC にスーパーユーザーまたは RBAC の承認 solaris.cluster.admin を提供する役割を使用してアクセスします。
主クラスタが複製モードで、自動同期機能がオンになっていることを確認します。
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 ソフトウェアが二次ボリュームを更新します。
主クラスタが複製モードでない場合は、複製モードにします。
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 |
クライアントマシンにディレクトリを作成します。
ディレクトリを主クラスタのアプリケーションにマウントし、マウントしたディレクトリを表示します。
ディレクトリを二次クラスタのアプリケーションにマウントし、マウントしたディレクトリを表示します。
主クラスタのアプリケーションからディレクトリのマウントを解除します。
client-machine# umount /dir |
主クラスタのアプリケーションリソースグループをオフラインにします。
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 |
主クラスタをロギングモードに変更します。
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 |
ディスクのデータボリュームに書き込みが行われると、同じディスクのビットマップファイルが更新されます。複製は行われません。
PathPrefix ディレクトリが使用可能であることを確認します。
nodeC# mount | grep /global/etc |
二次クラスタのアプリケーションリソースグループをオンラインにします。
nodeC# clresourcegroup online -n nodeC nfs-rg |
クライアントマシンにスーパーユーザーとしてアクセスします。
次のようなプロンプトが表示されます。
client-machine# |
手順 4 で作成したディレクトリを二次クラスタのアプリケーションにマウントします。
client-machine# mount -o rw lhost-nfsrg-sec:/global/mountpoint /dir |
マウントしたディレクトリを表示します。
client-machine# ls /dir |
主クラスタのアプリケーションをマウントされたディレクトリに戻します。
二次クラスタのアプリケーションリソースグループをオフラインにします。
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 |
グローバルボリュームを二次クラスタからマウント解除します。
nodeC# umount /global/mountpoint |
主クラスタのアプリケーションリソースグループをオンラインにします。
nodeA# clresourcegroup online -n nodeA nfs-rg |
主クラスタを複製モードに変更します。
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 エントリを更新します。詳細については、「フェイルオーバーまたはスイッチオーバーの管理ガイドライン」を参照してください。
ここでは、次の手順について説明します。
nodeA および nodeC にスーパーユーザーまたは RBAC の承認 solaris.cluster.admin を提供する役割を使用してアクセスします。
主クラスタをロギングモードに変更します。
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 |
ディスクのデータボリュームに書き込みが行われると、同じデバイスグループのビットマップボリュームが更新されます。複製は行われません。
主クラスタと二次クラスタがロギングモードで、自動同期がオフであることを確認します。
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 |
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 でなければなりません。
二次クラスタで主クラスタからのテイクオーバーの準備ができていることを確認します。
nodeC# fsck -y /dev/vx/rdsk/devgrp/vol01 |
二次クラスタにスイッチオーバーします。
nodeC# clresourcegroup switch -n nodeC nfs-rg |
「DNS エントリを更新する」に進みます。
DNS がクライアントをクラスタにどのようにマッピングするかについては、図 4–8 を参照してください。
手順「スイッチオーバーを呼び出す」を完了します。
nsupdate コマンドを開始します。
詳細は、nsupdate(1M) のマニュアルページを参照してください。
両方のクラスタについて、アプリケーションリソースグループの論理ホスト名とクラスタ 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 |
主クラスタの IP アドレス (逆順) です。
二次クラスタの IP アドレス (逆順) です。
秒単位の有効時間です。一般的な値は 3600 になります。
両方のクラスタについて、アプリケーションリソースグループの論理ホスト名とクラスタ 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 |
二次クラスタの IP アドレス (正順) です。
主クラスタの IP アドレス (正順) です。