この章では、広域デバイス、ディスクパス監視、およびクラスタファイルシステムの管理手順を説明します。
この章で説明する手順は次のとおりです。
ディスクデバイスグループを追加および登録する (Solstice DiskSuite/Solaris Volume Manager)
ディスクデバイスグループを削除して登録を解除する (Solstice DiskSuite/Solaris Volume Manager )
ディスクデバイスグループからノードを削除する (Solstice DiskSuite/Solaris Volume Manager)
SPARC: ディスクをカプセル化する際に新しいディスクグループを作成する (VERITAS Volume Manager)
SPARC: 新しいボリュームを既存のディスクデバイスグループに登録する (VERITAS Volume Manager)
SPARC: 既存のディスクグループをディスクデバイスグループに変更する (VERITAS Volume Manager)
SPARC: ディスクデバイスグループに新しいマイナー番号を割り当てる (VERITAS Volume Manager)
SPARC: ディスクグループをディスクデバイスグループとして登録する (VERITAS Volume Manager)
この章に関連する手順の概要については、表 4–2を参照してください。
広域デバイス、広域名前領域、ディスクデバイスグループ、ディスクパス監視、およびクラスタファイルシステムの概念については、『Sun Cluster の概念 (Solaris OS 版)』を参照してください。
Sun Cluster ディスクデバイスグループの管理方法は、クラスタにインストールされているボリューム管理ソフトウェアによって決まります。 Solstice DiskSuite/Solaris Volume Manager はクラスタ対応なので、Solstice DiskSuite/Solaris Volume Manager の metaset(1M) コマンドを使用して、ディスクデバイスグループを追加、登録、および削除できます。 VERITAS Volume Manager (VxVM) を使用している場合、VxVM コマンドを使用してディスクグループを作成し、 scsetup(1M) ユーティリティを使用し、ディスクグループを Sun Cluster ディスクデバイスグループとして登録します。 VxVM ディスクデバイスグループを削除するには、scsetup コマンドと VxVM コマンドの両方を使用します。
Sun Cluster ソフトウェアは、クラスタ内のディスクデバイスやテープデバイスごとに、raw ディスクデバイスグループを自動的に作成します。 ただし、クラスタデバイスグループは広域デバイスとしてアクセスされるまでオフラインのままです。 ディスクデバイスグループやボリューム管理ソフトウェアのディスクグループを管理する際は、グループの主ノードであるクラスタから実行する必要があります。
広域名前空間はインストール中に自動的に設定され、 Solaris オペレーティング環境の再起動中に自動的に更新されるため、通常、広域デバイス名前空間は管理する必要はありません。 ただし、広域名前空間を更新する必要がある場合は、任意のクラスタノードから scgdevs(1M) コマンドを実行できます。 このコマンドにより、その他のすべてのクラスタノードだけでなく、今後クラスタに結合する可能性があるノードでも広域名前空間を更新できます。
広域デバイスのアクセス権に加えた変更は、Solstice DiskSuite/Solaris Volume Manager およびディスクデバイスのクラスタのすべてのノードには自動的に伝達されません。 広域デバイスのアクセス権を変更する場合は、クラスタ内のすべてのノードで手作業でアクセス権を変更する必要があります。 たとえば、広域デバイス /dev/global/dsk/d3s0 のアクセス権を 644 に変更する場合は、次のコマンドを実行する必要があります。
# chmod 644 /dev/global/dsk/d3s0
このコマンドは、クラスタ内のすべてのノードで実行してください。
VxVM は、chmod コマンドをサポートしません。 VxVM で広域デバイスのアクセス権を変更する方法については、VxVM の管理者ガイドを参照してください。
クラスタ内のディスクデバイスやテープデバイス上で動的再構成 (DR) を実行するときには、いくつかの問題を考慮する必要があります。
Sun Cluster の動的再構成 (DR) のサポートには、Solaris の DR 機能に述べられている必要条件、手順、および制限がすべて適用されます。 ただし、オペレーティング環境の休止操作は除きます。 したがって、Sun Cluster ソフトウェアで DR 機能を使用する前には必ず、Solaris の DR 機能についての説明を熟読してください。 特に、DR Detach 操作中に、ネットワークに接続されていない入出力デバイスに影響する問題について確認してください。
主ノードのアクティブなデバイス上では DR 削除操作を実行できません。 DR 操作を実行できるのは、主ノードのアクティブでないデバイスか、二次ノードの任意のデバイス上でだけです。
DR 操作が終了すると、クラスタのデータアクセスが前と同じように続けられます。
Sun Cluster は、定足数デバイスの使用に影響を与える DR 操作を拒否します。 詳細については、 定足数デバイスへの動的再構成を参照してください。
二次ノードに対して DR 操作を行っているときに現在の主ノードに障害が発生すると、クラスタの可用性が損なわれます。 新しい二次ノードが提供されるまで、主ノードにはフェイルオーバーする場所がありません。
広域デバイス上で DR 操作を実行するには、次の手順をその順番どおりに行います。
表 4–1 Task Map: ディスクデバイスとテープデバイスでの動的再構成
目次 |
参照箇所 |
---|---|
1. アクティブなデバイスグループに影響するような DR 操作を現在の主ノードに実行する必要がある場合、DR 削除操作をデバイス上で実行する前に、主ノードと二次ノードの切替えを実行 | |
2. 削除するデバイス上で DR 削除操作を実行します。 |
「Solaris 8 on Sun Hardware」コレクションと「Solaris 9 on Sun Hardware」コレクションの『Sun Enterprise 10000 DR Configuration Guide』と『Sun Enterprise 10000 Dynamic Reconfiguration Reference Manual』 |
Sun Cluster で VxVM 名前空間を保持するには、VxVM のディスクグループまたはボリュームの変更を Sun Cluster ディスクデバイスグループの構成の変更として登録する必要があります。 変更を登録することによって、すべてのクラスタノードを確実に更新できます。 名前空間に影響を与える構成の変更の例としては、ボリュームの追加、削除、名前変更などがあります。 また、ボリュームのアクセス権、所有者、グループID の変更なども名前空間に影響を与えます。
ディスクグループを Sun Cluster ディスクデバイスグループとしてクラスタに登録した後は、VxVM コマンドを使用して VxVM ディスクグループをインポートまたはデポートしてはいけません。 ディスクグループのインポートやデポートが必要な場合は、すべて Sun Cluster ソフトウェアによって処理します。
各 VxVM ディスクグループには、クラスタ全体で一意のマイナー番号が与えられています。 デフォルトでは、ディスクグループを作成したときに、VxVM によって 1000 の倍数の乱数がディスクグループのベースマイナー番号として選択されます。 少数のディスクグループしかないほとんどの構成では、このマイナー番号で十分一意性を保証できます。 ただし、新たに作成したディスクグループのマイナー番号が、以前別のクラスタノードにインポートしたディスクグループのマイナー番号と衝突することがあります。 この場合、Sun Cluster ディスクデバイスグループは登録できません。 この問題を解消するには、新しいディスクグループに一意の値である新しいマイナー番号を付けたうえで、Sun Cluster ディスクデバイスグループとして登録してください。
ミラー化したボリュームを設定している場合、ダーティーリージョンログ (DRL) を使用すると、ノードに障害が発生してからボリュームが回復するまでの時間を短縮できます。 入出力のスループットが低下することになりますが、DRL の使用を強くお勧めします。
VxVM は、chmod コマンドをサポートしません。 VxVM で広域デバイスのアクセス権を変更する方法については、VxVM の管理者ガイドを参照してください。
Sun Cluster 3.1 4/04 ソフトウェアは、同じノードから複数のパスを管理する VxVM Dynamic Multipathing (DMP) をサポートしません。
VxVM を使用して Oracle Parallel Server/Real Application Clusters 用の共有ディスクグループを設定する場合、『VERITAS Volume Manager Administrator's Reference Guide』に説明されている VxVM のクラスタ機能を使用します。 Oracle Parallel Server/Real Application Clusters 用の共有ディスクグループの作成は、その他のディスクグループの作成と異なります。 Oracle Parallel Server/Real Application Clusters 用の共有ディスクグループをインポートするには、 vxdg -s を使用する必要があります。 Oracle Parallel Server/Real Application Clusters 用の共有ディスクグループをクラスタフレームワークに登録してはいけません。 VxVM ディスクグループを作成する方法については、SPARC: ディスクの初期化時に新しいディスクグループを 作成する (VERITAS Volume Manager) を参照してください。
クラスタファイルシステムを管理するのに特別な Sun Cluster コマンドは必要ありません。 クラスタファイルシステムを管理するには、他の Solaris ファイルシステムを管理するときと同じように、Solaris の標準のファイルシステムコマンド (mount や newfs など) を使用します。 クラスタファイルシステムをマウントするには、mount コマンドに -g オプションを指定します。 また、起動時に自動的にマウントすることもできます。
クラスタファイルシステムがファイルを読み取るとき、ファイルシステムはファイルのアクセス時間を更新しません。
次の VxFS 機能は Sun Cluster 3.1 構成ではサポートされません。
クイック入出力
スナップショット
記憶装置チェックポイント
convosync (Convert O_SYNC)
mincache
qlog、delaylog、 tmplog
VERITAS CFSには VERITAS クラスタ機能および VCS が必要
キャッシュアドバイザリを使用できますが、効果が認められるのは特定のノードに限られます。
クラスタ構成でサポートされる VxFS のその他の機能とオプションはすべて、Sun Cluster 3.1 ソフトウェアでサポートされます。 クラスタ構成でサポートされる VxFS オプションの詳細については、VxFS のマニュアルを参照してください。
次に示す VxFS を使って高可用性ファイルシステムを作成する方法に関する指針は、Sun Cluster 3.1 4/04 構成に固有のものです。
VxFS マニュアルの手順に従って VxFS ファイルシステムを作成します。
主ノードから VxFS ファイルシステムをマウントおよびマウント解除します。 主ノードは、VxFS ファイルシステムが存在するディスクをマスターします。 二次ノードから VxFS ファイルシステムをマウントまたはマウント解除すると、失敗することがあります。
VxFS の管理コマンドはすべて、VxFS クラスタファイルシステムの主ノードから実行します。
次に示す VxFS を管理する方法に関する指針は、Sun Cluster 3.1 4/04 構成に固有のものではありません。 しかし、これらのガイドラインは UFS クラスタファイルシステムを管理する方法とは異なります。
VxFS クラスタファイルシステム上にあるファイルは、クラスタ内にある任意のノードから管理できます。 例外は ioctls で、ioctls だけは主ノードから実行する必要があります。 管理コマンドが ioctl に関連するかどうかがわからない場合は、主ノードからコマンドを発行します。
VxFS クラスタファイルシステムが二次ノードにフェイルオーバーされると、フェイルオーバー時に実行中であったすべての標準システム呼び出し操作は、新しい主ノードで透過的に再実行されます。 ただし、フェイルオーバー時に実行していた ioctl 関連の操作は失敗します。 VxFS クラスタファイルシステムのフェイルオーバーの後で、このクラスタファイルシステムの状態を調べる必要があります。 フェイルオーバー以前に古い主ノードから実行された管理コマンドには修正処理が必要になることもあります。 詳細については、VxFS のマニュアルを参照してください。
scsetup(1M) ユーティリティは、scconf(1M) コマンドの対話的なインタフェースです。 scsetup は scconf コマンドを生成します。 生成されるコマンドについては、各説明の後にある例を参照してください。
Sun Cluster ソフトウェアは、クラスタ内のディスクデバイスやテープデバイスごとに、raw ディスクデバイスグループを自動的に作成します。 ただし、クラスタデバイスグループは広域デバイスとしてアクセスされるまでオフラインのままです。
目次 |
参照箇所 |
---|---|
再構成再起動せずに広域デバイス名前空間を更新 - scgdevs(1M) を使用します。 | |
Solstice DiskSuite/Solaris Volume Manager ディスクセットを追加してディスクデバイスグループとして登録 - metaset(1M) を使用します。 |
ディスクデバイスグループを追加および登録する (Solstice DiskSuite/Solaris Volume Manager) |
Solstice DiskSuite/Solaris Volume Manager ディスクデバイスグループを構成から削除 - metaset と metaclear(1M) を使用します。 |
ディスクデバイスグループを削除して登録を解除する (Solstice DiskSuite/Solaris Volume Manager ) |
すべてのディスクデバイスグループからノードを削除 - scconf、metaset、scsetup を使用します。 | |
Solstice DiskSuite/Solaris Volume Manager ディスクデバイスグループからノードを削除 - metaset を使用します。 |
ディスクデバイスグループからノードを削除する (Solstice DiskSuite/Solaris Volume Manager) |
SPARC: VERITAS Volume Manager ディスクグループをディスクデバイスグループとして追加 - VxVM コマンドと scsetup(1M) を使用します。 |
SPARC: ディスクの初期化時に新しいディスクグループを 作成する (VERITAS Volume Manager)
SPARC: ディスクをカプセル化する際に新しいディスクグループを作成する (VERITAS Volume Manager)
SPARC: 新しいボリュームを既存のディスクデバイスグループに登録する (VERITAS Volume Manager)
SPARC: 既存のディスクグループをディスクデバイスグループに変更する (VERITAS Volume Manager)
SPARC: ディスクデバイスグループに新しいマイナー番号を割り当てる (VERITAS Volume Manager)
SPARC: ディスクグループをディスクデバイスグループとして登録する (VERITAS Volume Manager)
|
SPARC: VERITAS Volume Manager ディスクデバイスグループを構成から削除 - scsetup を使用して、scconf を生成します。 |
SPARC: ディスクデバイスグループからボリュームを削除する (VERITAS Volume Manager)
|
SPARC: VERITAS Volume Manager ディスクデバイスグループにノードを追加 - scsetup を使用して、scconf を生成します。 | |
SPARC: VERITAS Volume Manager ディスクデバイスグループからノードを削除 - scsetup を使用して、scconf を生成します。 | |
raw ディスクデバイスグループからノードを削除 - scconf(1M) を使用します。 | |
ディスクデバイスグループの属性の変更 - scsetup を使用して、scconf を生成します。 | |
ディスクデバイスグループと属性の表示 - scconf を使用します。 | |
デバイスグループの二次ノード数の変更 - scsetup を使用して、scconf を生成します。 | |
ディスクデバイスグループの主ノードの切替え - scswitch(1M) を使用します。 | |
ディスクデバイスグループを保守状態に変更 - metaset または vxdgを使用します。 |
新しい広域デバイスを追加するときに、scgdevs(1M) を実行して手作業で広域デバイス名前空間を更新します。
コマンドを実行するノードがクラスタのメンバーでない場合や、 /global/.devices/node@ nodeID ファイルシステムがマウントされていない場合は、scgdevs コマンドを実行しても無効です。
次に、scgdevs が正常に実行された場合に生成される出力例を示します。
# scgdevs Configuring the /dev/global directory (global devices)... obtaining access to all attached disks reservation program successfully exiting |
metaset コマンドを使用して、Solstice DiskSuite/Solaris Volume Manager ディスクセットを作成し、このディスクセットを Sun Cluster ディスクデバイスグループとして登録します。 ディスクデバイスグループには、ディスクセットを登録するときにディスクセットに割り当てた名前が自動的に割り当てられます。
ディスクセットを作成するディスクに接続されているノードでスーパーユーザーになります。
構成に必要なメタデバイス名の個数を計算して、各ノード上で /kernel/drv/md.conf ファイルを変更します。
『Sun Cluster ソフトウェアのインストール (Solaris OS 版)』の「メタデバイス名またはボリューム名とディスクセットの数を算出する」を参照してください。
metaset コマンドを使用して、Solstice DiskSuite/Solaris Volume Manager ディスクセットを追加し、このディスクセットをディスクデバイスグループとして Sun Cluster に登録します。
# metaset -s diskset -a -h nodelist |
作成するディスクセットを指定します。
ディスクセットをマスターできるノードの一覧を追加します。
metaset コマンドを実行して設定した Solstice DiskSuite/Solaris Volume Manager デバイスグループは、そのデバイスグループに含まれるノード数に関わらず、デフォルトで二次ノードになります。 二次ノード数を変更するには、デバイスグループを作成した後に scsetup(1M) ユーティリティを使用します。 ディスクのフェイルオーバーの詳細については、デバイスグループの二次ノードの希望数を変更する を参照してください。
ディスクデバイスグループが追加されたことを確認します。
ディスクデバイスグループ名は metaset に指定したディスクセット名と一致します。
# scconf -p | grep disk-device-group |
次は、ディスクセットとディスクデバイスグループを作成して、ディスクデバイスグループが作成されたことを確認する例です。
# metaset -s dg-schost-1 -a -h phys-schost-1 # scconf -p | grep dg-schost-1 デバイスグループ名: dg-schost-1 |
ディスクデバイスグループとは、Sun Cluster に登録している Solstice DiskSuite/Solaris Volume Manager ディスクセットのことです。 Solstice DiskSuite/Solaris Volume Manager ディスクデバイスグループを削除するには、metaclear と metaset コマンドを使用します。 これらのコマンドは、Sun Cluster ディスクデバイスグループと同じ名前を持つディスクデバイスグループを削除して、ディスクグループの登録を解除します。
ディスクセットを削除する方法については、Solstice DiskSuite/Solaris Volume Manager のマニュアルを参照してください。
すべてのディスクデバイスグループの潜在的な主ノードからクラスタノードを削除する場合は、この手順を使用します。
すべてのディスクデバイスグループの潜在的な主ノードとして削除を行うノード上でスーパーユーザーになります。
削除するノードがメンバーになっているディスクデバイスグループを確認します。
各ディスクデバイスグループの Device group node list からこのノード名を検索します。
# scconf -p | grep ¨Device group" |
手順 2 で特定したディスクデバイスグループの中に、デバイスグループタイプが SDS/ SVM のものがあるかどうかを確認します。
ある場合は、ディスクデバイスグループからノードを削除する (Solstice DiskSuite/Solaris Volume Manager)の各手順を実行します。
ない場合は、手順 4に進みます。
手順 2 で特定したディスクデバイスグループの中に、デバイスグループタイプが VxVM のものがあるかどうかを確認します。
ある場合は、SPARC: ディスクデバイスグループからノードを削除する (VERITAS Volume Manager)の各手順を実行します。
ない場合は、手順 5に進みます。
削除するノードがメンバーになっている raw ディスクデバイスグループを特定します。
次のコマンドの -pvv には、2 つの「v」が指定されています。 raw ディスクデバイスグループを表示するためには、2 つめの「v」が必要です。(1 つめの「v」は出力を冗長形式にするためのオプションです)
# scconf -pvv | grep ¨Device group¨ |
手順 5で表示されたディスクデバイスグループのリストの中に、デバイスグループタイプが Disk、Local_Disk、またはその両方に該当するのものがあるかどうかを確認します。
ある場合は、SPARC: raw ディスクデバイスグループからノードを削除するの各手順を実行します。
ない場合は、手順 7に進みます。
すべてのディスクデバイスグループの潜在的な主ノードのリストからノードが削除されていることを確認します。
ノードがどのディスクデバイスグループの潜在的な主ノードのリストにも存在しなければ、このコマンドは何も返しません。
# scconf -pvv | grep ¨Device group¨ | grep nodename |
Solstice DiskSuite/Solaris Volume Manager ディスクデバイスグループの潜在的な主ノードのリストからクラスタノードを削除するには、次の手順を使用します。 ノードを削除したいディスクグループデバイスごとに metaset コマンドを繰り返します。
ノードがまだグループのメンバーであり、かつ、グループが SDS/SVM デバイスグループであることを確認します。
Solstice DiskSuite/Solaris Volume Manager のディスクデバイスグループは、デバイスグループタイプが SDS/SVM のものです。
phys-schost-1% scconf -pv | grep '(global-galileo)' (global-galileo) デバイスグループのタイプ: SDS/SVM (global-galileo) デバイスグループの有効なフェイルバック: no (global-galileo) デバイスグループノードリスト: phys-schost-1, phys-schost-2 (global-galileo) Diskset name: global-galileo phys-schost-1% |
どのノードがデバイスグループの現在の主ノードであるかを特定します。
# scstat -D |
変更したいディスクデバイスグループを所有しているノードでスーパーユーザーになります。
ディスクデバイスグループからこのノードのホスト名を削除します。
# metaset -s setname -d -h nodelist |
ディスクデバイスグループの名前を指定します。
-h で指定されたノードをディスクデバイスグループから削除します。
ディスクデバイスグループをマスターできるノード群からこのノードを削除します。
更新が完了するまでに数分間かかることがあります。
コマンドが正常に動作しない場合は、コマンドに -f (Force) オプションを追加します。
# metaset -s setname -d -f -h nodelist |
潜在的な主ノードとしてノードを削除するディスクデバイスグループごとに手順 4 を繰り返します。
ディスクデバイスグループからノードが削除されたことを確認します。
ディスクデバイスグループ名は metaset に指定したディスクセット名と一致します。
phys-schost-1% scconf -pv |grep デバイスグループの ノードリスト: phys-schost-1, phys-schost-2, phys-schost-1% |
次に、ディスクデバイスグループ構成からホスト名 phys-schost-2 を削除する例を示します。 この例では、指定したディスクデバイスグループから phys-schost-2 を潜在的な主ノードとして削除します。 ノードの削除を確認するには、scstat-D コマンドを実行し、 削除したノードが画面に表示されていないことを確認します。
[ノードの Solstice DiskSuite/Solaris Volume Manager ディスクデバイスグループ (2) を確認する:] # scconf -pv | grep Device デバイスグループ名: dg-schost-1 デバイスグループのタイプ: SDS/SVM デバイスグループの有効なフェイルバック: no デバイスグループのノードリスト: phys-schost-1, phys-schost-2 デバイスグループの順序つきノードリスト: yes デバイスグループのディスクセット名: dg-schost-1 [ノードのディスクデバイスグループを確認する:] # scstat -D -- デバイスグループのサーバー -- デバイスグループ プライマリ セカンダリ ------------ ------- --------- デバイスグループのサーバー: dg-schost-1 phys-schost-1 phys-schost-2 [スーパーユーザーになる.] [ディスクデバイスグループからホスト名を削除する:] # metaset -s dg-schost-1 -d -h phys-schost-2 [ノードが削除されたことを確認する:] phys-schost-1% scconf -pv |grep デバイスグループのサーバー -- デバイスグループ プライマリ セカンダリ ------------ ------- --------- デバイスグループのノードリスト: dg-schost-1, phys-schost-2, |
クラスタにディスクセットを 3 つ以上作成する場合は、ディスクセットを作成する前に次の各手順を行う必要があります。 これらの手順は、ディスクセットを初めてインストールする場合でも、完全に構成されているクラスタにディスクセットをさらに追加する場合でも必要です。
md_nsets 変数が十分に大きな値であることを確認します。 この値は、クラスタに作成する予定のディスクセットの合計数より大きな値である必要があります。
クラスタの任意のノードで、/kernel/drv/md.conf ファイルの md_nsets 変数の値を検査します。
クラスタ内にあるディスクセットの数が md_nsets の既存の値から 1 を引いた値よりも大きい場合、各ノード上で md_nsets の値を増やします。
ディスクセットの最大数は md_nsets の値から 1 を引いた値です。 md_nsets に設定できる最大値は 32 です。
クラスタの各ノードの /kernel/drv/md.conf ファイルが同じであるかを確認します。
このガイドラインに従わないと、重大な Solstice DiskSuite/Solaris Volume Manager エラーが発生し、データが失われることがあります。
ノードのどれか 1 つでクラスタを停止します。
# scshutdown -g0 -y |
SPARC:
ok boot |
x86:
<<< Current Boot Parameters >>> Boot path: /pci@0,0/pci8086,2545@3/pci8086,1460@1d/pci8086,341a@ 7,1/sd@0,0:a Boot args: Type b [file-name] [boot-flags] <ENTER> to boot with options or i <ENTER> to enter boot interpreter or <ENTER> to boot with defaults <<< timeout in 5 seconds >>> Select (b)oot or (i)nterpreter: b |
クラスタの各ノードで devfsadm(1M) コマンドを実行します。
このコマンドは、すべてのノードで同時に実行できます。
クラスタのノードの 1 つで、scgdevs (1M) コマンドを実行します。
ディスクセットの作成に移る前に、各ノードで scgdevs コマンドが終了しているかを確認します。
ノードの 1 つで scgdevs コマンドを実行すると、このコマンドはリモートから自分自身をすべてのノードで呼び出します。 scgdevs コマンドが処理を終了したかどうかを確認するには、クラスタの各ノードで次のコマンドを実行します。
% ps -ef | grep scgdevs |
次の手順は、ディスクを初期化する場合にのみ必要となります。 ディスクをカプセル化する場合は、SPARC: ディスクをカプセル化する際に新しいディスクグループを作成する (VERITAS Volume Manager)を参照してください。
VxVM ディスクグループを追加したら、ディスクデバイスグループを登録する必要があります。
VxVM を使用して Oracle Parallel Server/Real Application Clusters 用の共有ディスクグループを設定する場合、『VERITAS Volume Manager Administrator's Reference Guide』に説明されている VxVM のクラスタ機能を使用します。
追加しようとしているディスクグループを構成するディスクに物理的に接続されている任意のクラスタノード上でスーパーユーザーになります。
VxVM のディスクグループとボリュームを作成します。
ディスクグループとボリュームは任意の方法で作成してください。
ミラー化したボリュームを設定している場合、ダーティーリージョンログ (DRL) を使用すると、ノードに障害が発生してからボリュームが回復するまでの時間を短縮できます。 ただし、DRL を使用すると I/O スループットが低下することがあります。
この手順を完了する方法については、VERITAS Volume Manager のマニュアルを参照してください。
VxVM ディスクグループを Sun Cluster ディスクデバイスグループとして登録します。
詳細は、SPARC: ディスクグループをディスクデバイスグループとして登録する (VERITAS Volume Manager)を参照してください。
Oracle Parallel Server/Real Application Clusters 用の共有ディスクグループをクラスタフレームワークに登録してはいけません。
次の手順は、ディスクをカプセル化する場合にのみ必要となります。 ディスクを初期化する場合は、SPARC: ディスクの初期化時に新しいディスクグループを 作成する (VERITAS Volume Manager) の手順を使用します。
ルート以外のディスクを Sun Cluster ディスクデバイスグループに変更するには、そのディスクを VxVM ディスクグループとしてカプセル化してから、そのディスクグループを Sun Cluster ディスクデバイスグループとして登録します。
ディスクのカプセル化は、VxVM ディスクグループを初めて作成するときのみサポートされています。 VxVM ディスクグループを作成して、Sun Cluster ディスクデバイスグループとして登録した後は、そのディスクグループには、初期化してもよいディスクだけを登録します。
VxVM を使用して Oracle Parallel Server/Real Application Clusters 用の共有ディスクグループを設定する場合、『VERITAS Volume Manager Administrator's Reference Guide』に説明されている VxVM のクラスタ機能を使用します。
クラスタ内の任意のノード上でスーパーユーザーになります。
/etc/vfstab ファイルに、カプセル化するディスクのファイルシステムのエントリがある場合は、mount at boot オプションを必ず no に設定します。
ディスクをカプセル化して Sun Cluster ディスクデバイスグループとして登録した後は、この設定を yes に設定し直します。
ディスクをカプセル化します。
vxdiskadm のメニューまたはグラフィカルユーザーインタフェースを使用して、ディスクをカプセル化します。 VxVM では、2 つの空きパーティションのほかに、ディスクの始点または終端に未割当てのシリンダが必要です。 また、スライス 2 をディスク全体に設定する必要もあります。 詳細は、vxdiskadm のマニュアルページを参照してください。
ノードを停止して再起動します。
scswitch(1M) コマンドを使用して、すべてのリソースグループとデバイスグループを主ノードから次の優先ノードに切り替えます。 shutdown を使用して、ノードを停止して再起動します。
# scswitch -S -h node[,...] # shutdown -g0 -y -i6 |
必要であれば、すべてのリソースグループとデバイスグループを元のノードにスイッチバックします。
リソースグループとデバイスグループが、もともと主ノードにフェイルバックするように構成されていた場合、この手順は必要ありません。
# scswitch -z -D disk-device-group -h node[,...] # scswitch -z -g resource-group -h node[,...] |
VxVM ディスクグループを Sun Cluster ディスクデバイスグループとして登録します。
詳細は、SPARC: ディスクグループをディスクデバイスグループとして登録する (VERITAS Volume Manager)を参照してください。
Oracle Parallel Server/Real Application Clusters 用の共有ディスクグループをクラスタフレームワークに登録してはいけません。
新しいボリュームを既存の VxVM ディスクデバイスグループに追加する場合、次の手順は、オンラインであるディスクデバイスグループの主ノードから実行します。
ボリュームを追加したあとで、SPARC: ディスクグループの構成変更を登録する (VERITAS Volume Manager)の手順に従って構成変更の内容を登録する必要があります。
クラスタ内の任意のノードでスーパーユーザーになります。
新しいボリュームを追加するディスクデバイスグループの主ノードを確認します。
# scstat -D |
ディスクデバイスグループがオフラインである場合、デバイスグループをオンラインにします。
# scswitch -z -D disk-device-group -h node[,...] |
指定したデバイスグループを切り替えます。
ディスクデバイスグループの切替え先のノードの名前を指定します。 このノードが新しい主ノードになります。
主ノード (ディスクデバイスグループを現在マスターしているノード) から、ディスクグループに VxVM ボリュームを作成します。
VxVM ボリュームの作成方法は、VERITAS Volume Manager のマニュアルを参照してください。
VxVM ディスクグループに加えた変更を登録して、広域名前空間を更新します。
SPARC: ディスクグループの構成変更を登録する (VERITAS Volume Manager)を参照してください。
既存の VxVM ディスクグループを Sun Cluster ディスクデバイスグループに変更するには、ディスクグループを現在のノードにインポートしてから、そのディスクグループを Sun Cluster ディスクデバイスグループとして登録します。
クラスタ内の任意のノード上でスーパーユーザーになります。
VxVM ディスクグループを現在のノードにインポートします。
# vxdg import diskgroup |
VxVM ディスクグループを Sun Cluster ディスクデバイスグループとして登録します。
詳細は、SPARC: ディスクグループをディスクデバイスグループとして登録する (VERITAS Volume Manager)を参照してください。
マイナー番号が他のディスクグループと衝突してディスクデバイスグループの登録が失敗する場合、新しいディスクグループに未使用の新しいマイナー番号を割り当てる必要があります。 新しいマイナー番号を割り当てた後で、登録手順を再度実行し、ディスクグループを Sun Cluster ディスクデバイスグループとして登録します。
クラスタ内の任意のノード上でスーパーユーザーになります。
使用中のマイナー番号を確認します。
# ls -l /global/.devices/node@nodeid/dev/vx/dsk/* |
新しいディスクグループのベースとなるマイナー番号として、使用されていない別の 1000 の倍数を選択します。
ディスクグループに新しいマイナー番号を割り当てます。
# vxdg reminor diskgroup base-minor-number |
VxVM ディスクグループを Sun Cluster ディスクデバイスグループとして登録します。
詳細は、SPARC: ディスクグループをディスクデバイスグループとして登録する (VERITAS Volume Manager)を参照してください。
次の例は、マイナー番号 16000 から 16002 と 4000 から 4001 が使用されていることを示しています。ここでは、vxdg reminor コマンドを使用して新しいディスクデバイスグループにベースとなるマイナー番号 5000 を割り当てています。
# ls -l /global/.devices/node@nodeid/dev/vx/dsk/* /global/.devices/node@nodeid/dev/vx/dsk/dg1 brw------- 1 root root 56,16000 Oct 7 11:32 dg1v1 brw------- 1 root root 56,16001 Oct 7 11:32 dg1v2 brw------- 1 root root 56,16002 Oct 7 11:32 dg1v3 /global/.devices/node@nodeid/dev/vx/dsk/dg2 brw------- 1 root root 56,4000 Oct 7 11:32 dg2v1 brw------- 1 root root 56,4001 Oct 7 11:32 dg2v2 # vxdg reminor dg3 5000 |
次の手順では、scsetup(1M) ユーティリティを使用して、関連付けられている VxVM ディスクグループを Sun Cluster ディスクデバイスグループとして登録します。
ディスクデバイスグループをクラスタに登録した後は、VxVM コマンドを使用して VxVM ディスクグループをインポートまたはデポートしないでください。 VxVM ディスクグループやボリュームに変更を加えた場合は、SPARC: ディスクグループの構成変更を登録する (VERITAS Volume Manager)の手順に従って、ディスクデバイスグループの構成変更を登録してください。 この手順によって、広域名前空間が正しい状態になります。
VxVM ディスクデバイスグループを登録するには以下が必要です。
クラスタ内の任意のノードでのスーパーユーザー特権。
ディスクデバイスグループとして登録する VxVM ディスクグループの名前
ディスクデバイスグループをマスターするノードの優先順位
ディスクデバイスグループの二次ノードの希望数
優先順位を指定する場合は、最優先ノードが停止した後にクラスタに復帰するときに、ディスクデバイスグループを最優先ノードにスイッチバックするかどうかも指定します。
ノードの優先順位とフェイルバックのオプションの詳細については、scconf(1M) のマニュアルページを参照してください。
主ノード以外のクラスタノード (スペア) から二次ノードへの移行ノードの優先順位では 通常、デバイスグループの二次ノードのデフォルト数は 1 に設定されます。 デフォルトの設定では、主ノードが通常の動作中に複数の二次ノードをチェックすることによって発生する性能の低下を最小限に抑えます。 たとえば、4 ノードクラスタでは、デフォルトで、1 つが主ノード、1 つが二次ノード、そして 2 つがスペアノードに構成されます。 SPARC: 二次ノードの希望数を設定する (VERITAS Volume Manager)も参照してください。
クラスタ内の任意のノード上でスーパーユーザーになります。
scsetup ユーティリティを実行します。
# scsetup |
メインメニューが表示されます。
4 (デバイスグループとボリューム) を入力して、VxVM ディスクデバイスグループで作業します。
「デバイスグループメニュー」が表示されます。
1 (VxVM ディスクグループをデバイスグループとして登録) を選択して、VxVM ディスクデバイスグループを登録します。
指示に従って、Sun Cluster ディスクデバイスグループとして登録する VxVM ディスクグループの名前を入力します。
Oracle Parallel Server/Real Application Clusters 用の共有ディスクグループを VxVM を使用して設定した場合、この共有ディスクグループをクラスタフレームワークに登録してはいけません。 『VERITAS Volume Manager Administrator's Reference Guide』に説明されている VxVM のクラスタ機能を使用します。
ディスクデバイスグループを登録しようとしたときに、次のようなエラーが表示された場合は、ディスクデバイスグループに新しいマイナー番号を割り当てます。
scconf: Failed to add device group - in use |
ディスクデバイスグループに新しいマイナー番号を割り当てる方法については、SPARC: ディスクデバイスグループに新しいマイナー番号を割り当てる (VERITAS Volume Manager)を参照してください。 この手順によって、既存のディスクデバイスグループが使用しているマイナー番号と衝突しない、新しいマイナー番号を割り当てることができます。
ディスクデバイスグループが登録され、オンラインになったことを確認します。
ディスクデバイスグループが適切に登録されている場合、次のコマンドを使用すると、新しいディスクデバイスグループの情報が表示されます。
# scstat -D |
クラスタに登録されている VxVM ディスクグループまたはボリュームの構成情報を変更した場合、scsetup(1M) を使用してディスクデバイスグループの同期をとる必要があります。 このような構成変更には、ボリュームの追加や削除、既存ボリュームのグループ、所有者、アクセス権の変更などがあります。 構成変更後に登録を行うと、広域名前空間が正しい状態になります。 広域デバイス名前空間を更新するを参照してください。
次に、scsetup で VxVM ディスクデバイスグループ (dg1) を登録する際に生成される scconf コマンドの例と、その検証手順を示します。 この例では、VxVM ディスクグループとボリュームは以前に作成されたものと想定しています。
# scsetup scconf -a -D type=vxvm,name=dg1,nodelist=phys-schost-1:phys-schost-2 # scstat -D -- デバイスグループのサーバー -- デバイスグループ プライマリ セカンダリ ------------ ------- --------- デバイスグループのサーバー: dg1 phys-schost-1 phys-schost-2 -- デバイスグループの状態 -- デバイスグループ 状態 ------------ ------ デバイスグループの状態: dg1 Online |
クラスタファイルシステムを追加するを参照し、 VxVM ディスクデバイスグループ上にクラスタファイルシステムを作成します。
マイナー番号に問題がある場合は、SPARC: ディスクデバイスグループに新しいマイナー番号を割り当てる (VERITAS Volume Manager)を参照してください。
VxVM ディスクグループやボリュームの構成情報を変更したときは、Sun Cluster ディスクデバイスグループに構成変更を登録する必要があります。 この登録によって、広域名前空間が正しい状態になります。
クラスタ内にある任意のノード上でスーパーユーザーになります。
scsetup(1M) ユーティリティを実行します。
# scsetup |
メインメニューが表示されます。
4 (デバイスグループとボリューム) を入力して、VxVM ディスクデバイスグループで作業します。
「デバイスグループメニュー」が表示されます。
2 (VxVM デバイスグループのボリューム情報の同期をとる) を選択して、構成の変更を登録します。
指示に従って、構成を変更した VxVM ディスクグループ名を入力します。
次に、scsetup で VxVM ディスクデバイスグループ (dg1) の変更を登録する際に生成される scconf コマンドの例を示します。 この例では、VxVM ディスクグループとボリュームは以前に作成されたものと想定しています。
# scsetup scconf -c -D name=dg1,sync |
numsecondaries プロパティは、主ノードに障害が発生した場合にデバイスグループをマスターできる、デバイスグループ内のノード数を指定します。 デバイスサービスの二次ノードのデフォルト数は 1 です。 この値には、1 からデバイスグループ内で動作している主ノード以外のプロバイダノード数までの任意の整数を設定できます。
この設定は、クラスタの性能と可用性のバランスをとるための重要な要因になります。 たとえば、二次ノードの希望数を増やすと、クラスタ内で同時に複数の障害が発生した場合でも、デバイスグループが生き残る可能性が増えます。 しかし、二次ノード数を増やすと、通常の動作中の性能が一様に下がります。 通常、二次ノード数を減らすと、性能が上がりますが、可用性が下がります。 しかし、二次ノード数を増やしても、必ずしも、当該のファイルシステムまたはデバイスグループの可用性が上がるわけではありません。 詳細については、『Sun Cluster の概念 (Solaris OS 版)』の「重要な概念 - 管理とアプリケーション開発」を参照してください。
クラスタ内の任意のノード上でスーパーユーザーになります。
scsetup(1M) ユーティリティを実行します。
# scsetup |
メインメニューが表示されます。
4 (デバイスグループとボリューム) を入力して、VxVM ディスクデバイスグループで作業します。
「デバイスグループメニュー」が表示されます。
6 (デバイスグループのキープロパティ変更) を選択して、デバイスグループの重要なプロパティを変更します。
「デバイスグループのプロパティ変更メニュー」が表示されます。
2 (numsecondaries プロパティを変更) を選択して、二次ノードの希望数を変更します。
指示に従って、ディスクデバイスグループに構成したい二次ノードの希望数を入力します。 適切な値を入力すると、対応する scconf コマンドが実行されます。 そして、ログが出力され、ユーザーは前のメニューに戻ります。
scconf -p コマンドを使用して、デバイスグループの構成を確認します。
# scconf -p | grep Device デバイスグループ名: dg-schost-1 デバイスグループのタイプ: VxVM デバイスグループの有効なフェイルバック: yes デバイスグループのノードリスト: phys-schost-1,phys-schost-2, phys-schost-3 デバイスグループの順序つきノードリスト: yes デバイスグループの希望のセカンダリ数: 1 デバイスグループのディスクセット名: dg-schost-1 |
VxVM ディスクグループ、または、クラスタに登録されているボリュームの構 成情報を変更した場合、scsetup を使用してディスクデバイスグループを登録する必要があります。 このような構成変更には、ボリュームの追加や削除、既存ボリュームのグループ、所有者、アクセス権の変更などがあります。 構成変更後に登録を行うと、広域名前空間が正しい状態になります。 広域デバイス名前空間を更新するを参照してください。
ディスクデバイスグループの主ノードと状態を確認します。
# scstat -D |
次に、デバイスグループ (diskgrp1) の二次ノードの希望数を構成するときに、scsetup によって生成される scconf コマンドの例を示します。 デバイスグループを作成した後に二次ノードの希望数を変更する方法については、デバイスグループの二次ノードの希望数を変更する を参照してください。
# scconf -a -D type=vxvm,name=diskgrp1, nodelist=host1:host2:host3,preferenced=true, \ failback=enabled,numsecondaries=2 |
ディスクデバイスグループからボリュームを削除した後は、SPARC: ディスクグループの構成変更を登録する (VERITAS Volume Manager)の手順に従って、ディスクデバイスグループに構成の変更を登録する必要があります。
クラスタ内の任意のノード上でスーパーユーザーになります。
ディスクデバイスグループの主ノードを確認します。
# scstat -D |
ディスクデバイスグループがオフラインのときは、オンラインにします。
# scswitch -z -D disk-device-group -h node[,...] |
切り替えを実行します。
切り替えるデバイスグループを指定します。
切り替え先のノードの名前を指定します。 このノードが新しい主ノードになります。
主ノード (ディスクデバイスグループを現在マスターしているノード) から、ディスクグループの VxVM ボリュームを削除します。
# vxedit -g diskgroup -rf rm volume |
ボリュームが含まれる VxVM ディスクグループを指定します。
指定したボリュームを削除します。
scsetup(1M) を使用して、ディスクデバイスグループの構成変更を登録し、広域名前空間を更新します。
SPARC: ディスクグループの構成変更を登録する (VERITAS Volume Manager)を参照してください。
Sun Cluster ディスクデバイスグループを削除すると、対応する VxVM ディスクグループはデポートされます(消去されるわけではない)。 ただし、VxVM ディスクグループが引き続き存在していても、再登録しない限りクラスタで使用することはできません。
次の手順では、scsetup(1M) ユーティリティを使用して、VxVM ディスクグループを削除して、Sun Cluster ディスクデバイスグループから登録を解除します。
クラスタ内の任意のノード上でスーパーユーザーになります。
ディスクデバイスグループをオフラインにします。
# scswitch -F -D disk-device-group |
ディスクデバイスグループをオフラインにします。
オフラインにするデバイスグループを指定します。
scsetup ユーティリティを実行します。
メインメニューが表示されます。
# scsetup |
4 (デバイスグループとボリューム) を入力して、VxVM デバイスグループで作業を行います。
「デバイスグループメニュー」が表示されます。
3 (VxVM デバイスグループ登録を解除) を選択して、VxVM デバイスグループの登録を解除します。
指示に従って、登録を解除する VxVM ディスクグループを入力します。
次に、VxVM ディスクデバイスグループ dg1 をオフラインにして、scsetup でディスクデバイスグループの削除と登録の解除を行う際に生成される scconf コマンドの例を示します。
# scswitch -F -D dg1 # scsetup scconf -r -D name=dg1 |
この手順では、scsetup(1M) ユーティリティを使用してディスクデバイスグループにノードを追加します。
VxVM ディスクデバイスグループにノードを追加するには以下が必要です。
クラスタ内のノードでのスーパーユーザー特権
ノードの追加先の VxVM デバイスグループの名前
追加するノードの名前または ノード ID
クラスタ内の任意のノード上でスーパーユーザーになります。
プロンプトで、scsetup コマンドを入力します。
# scsetup |
4 (デバイスグループとボリューム) を入力して、VxVM ディスクデバイスグループで作業します。
「デバイスグループメニュー」が表示されます。
4 (ノードを VxVM デバイスグループに追加) を選択して、VxVM ディスクデバイスグループにノードを追加します。
指示に従って、デバイスグループ名とノード名を入力します。
ノードが追加されたことを確認します。
次のコマンドを実行し、表示される新しいディスクのデバイスグループ情報を確認します。
# scconf -p |
次に、scsetup で VxVM ノード (phys-schost-3) を VxVM ディスクデバイスグループ (dg1) に追加する際に生成される scconf コマンドと、その検証手順の例を示します。
# scsetup scconf a D type=vxvm,name=dg1,nodelist=phys-schost-3 # scconf -p デバイスグループ名: dg1 デバイスグループのタイプ: VXVM デバイスグループの有効なフェイルバック: yes デバイスグループのノードリスト: phys-schost-1, phys-schost-3 |
VERITAS Volume Manager (VxVM) ディスクデバイスグループ (ディスクグループ) の潜在的な主ノードリストからクラスタノードを削除する場合は、この手順を使用します。
ノードがまだグループのメンバーであり、かつ、グループが VxVM デバイスグループであることを確認します。
デバイスグループタイプ VxVM は VxVM ディスクデバイスグループを示します。
phys-schost-1% scconf -pv | grep '(global-galileo)' (global-galileo) デバイスグループのタイプ: VxVM (global-galileo) デバイスグループの有効なフェイルバック: no (global-galileo) デバイスグループのノードリスト: phys-schost-1, phys-schost-2 (global-galileo) ディスクセット名: global-galileo phys-schost-1% |
現在のクラスタメンバーノードでスーパーユーザーになります。
scsetup(1M) コマンドを実行します。
# scsetup |
メインメニューが表示されます。
4 (デバイスグループとボリューム) を入力して、ディスクデバイスグループを再構成します。
5 (VxVM デバイスグループからノードを削除) を選択して、VxVM ディスクデバイスグループからノードを削除します。
プロンプトに従って、ディスクデバイスグループからクラスタノードを削除します。 次の情報を入力するよう求められます。
VxVM のデバイスグループ
ノード名
ノードが VxVM のディスクデバイスグループから削除されていることを確認します。
# scconf -p | grep Device |
この例では、dg1 という VxVM のディスクデバイスグループから phys-schost-1 というノードを削除します。
[ノードの VxVM ディスクデバイスグループを確認する:] # scconf -p | grep Device デバイスグループ名: dg1 デバイスグループのタイプ: VxVM デバイスグループの有効なフェイルバック: no デバイスグループのノードリスト: phys-schost-1, phys-schost-2 デバイスグループのディスクセット名: dg1 [スーパーユーザーになり scsetup ユーティリティーを実行する:] # scsetup 「デバイスグループとボリューム」を選択し、次に「VxVM デバイスグループからノードを削除」を選択する プロンプトが表示されたら「yes」と答える 次の情報が必要となる 項目: 例: VxVM device group name dg1 node names phys-schost-1 [scconf コマンドが適切に実行されたことを確認する:] scconf -r -D name=dg1,nodelist=phys-schost-1 コマンドの実行が正常に終了する scsetup デバイスグループメニューとメインメニューを終了する [ノードが削除されたことを確認する:] # scconf -p | grep Device デバイスグループ名: dg1 デバイスグループのタイプ: VxVM デバイスグループの有効なフェイルバック: no デバイスグループのノードリスト: phys-schost-2 デバイスグループのディスクセット名: dg1 |
VERITAS Volume Manager (VxVM) ディスクデバイスグループ (ディスクグループ) の潜在的な主ノードリストからクラスタノードを削除する場合は、この手順を使用します。
raw ディスクデバイスグループの潜在的主ノードリストからクラスタノードを削除する場合は、この手順を使用します。
削除するノード以外のクラスタノードでスーパーユーザーになります。
削除するノードに接続されているディスクデバイスグループを特定します。
Device group node list エントリからこのノード名を探します。
# scconf -pvv | grep Devicenodename | grep |
手順 2 で特定したディスクデバイスグループのうち、どれが raw ディスクデバイスグループであるかを特定します。
raw ディスクデバイスグループのデバイスグループタイプは Disk か Local_Disk です。
# scconf -pvv | grep group type |
すべての Local_Disk raw ディスクデバイスグループの localonly プロパティを無効にします。
# scconf -c -D name=rawdisk-device-group,localonly=false |
localonly プロパティについては、scconf_dg_rawdisk(1M) のマニュアルページを参照してください。
削除するノードに接続されているすべての raw ディスクデバイスグループの localonly プロパティが無効になっていることを確認します。
デバイスグループタイプ Disk は、この raw ディスクデバイスグループの localonly プロパティが無効になっていることを表します。
# scconf -pvv | grep group type |
手順 3 で特定したすべての raw ディスクデバイスグループからノードを削除します。
この手順は、削除するノードに接続されている raw ディスクデバイスグループごとに行う必要があります。
# scconf -r -D name=rawdisk-device-group,nodelist=nodename |
この例では、raw ディスクデバイスグループからノード (phys-schost-2) を削除します。 すべてのコマンドは、クラスタの別のノード (phys-schost-1) から実行します。
[削除したいノードに接続されているディスクデバイスグループを確認する:] phys-schost-1# scconf -pvv | grep phys-schost-2 | grep デバイスグループのノードリスト (dsk/d4) デバイスグループのノードリスト: phys-schost-2 (dsk/d2) デバイスグループのノードリスト: phys-schost-1, phys-schost-2 (dsk/d1) デバイスグループのノードリスト: phys-schost-1, phys-schost-2 [raw ディスクデバイスグループであることを確認する:] phys-schost-1# scconf -pvv | grep group type (dsk/d4) デバイスグループのタイプ: Local_Disk (dsk/d8) デバイスグループのタイプ: Local_Disk [ノード上の各ローカルディスクに対して localonly フラグを無効にする:] phys-schost-1# scconf -c -D name=dsk/d4,localonly=false [localonly フラグが無効になったことを確認する:] phys-schost-1# scconf -pvv | grep "グループのタイプ" (dsk/d4) デバイスグループのタイプ: Disk (dsk/d8) デバイスグループのタイプ: Local_Disk [すべてのraw ディスクデバイスグループからノードを削除する:] phys-schost-1# scconf -r -D name=dsk/d4,nodelist=phys-schost-2 phys-schost-1# scconf -r -D name=dsk/d2,nodelist=phys-schost-2 phys-schost-1# scconf -r -D name=dsk/d1,nodelist=phys-schost-2 |
ディスクデバイスグループの主所有権を確立する方法は、preferenced という所有 権設定属性の設定に基づきます。 この属性を設定していない場合は、ほかで所有されていないディスクデバイスグループの主所有者が、そのグループ内のディスクへのアクセスを試みる最初のノードになります。 一方、この属性を設定してある場合は、ノードが所有権の確立を試みる優先順位を指定する必要があります。
preferenced 属性を無効にすると、failback 属性も自動的に無効に設定されます。 ただし、preferenced 属性を有効または再有効にする場合は、failback 属性を有効にするか無効にするかを選択できます。
preferenced 属性を有効または再有効にした場合は、主所有権の設定一覧でノードの順序を確立し直す必要があります。
次の手順では、scsetup(1M) を使用して、Solstice DiskSuite/Solaris Volume Manager または VxVM ディスクデバイスグループの preferenced 属性と failback 属性を設定または設定解除します。
この手順を実行するには、属性値を変更するディスクデバイスグループの名前が必要です。
クラスタ内の任意のノード上でスーパーユーザーになります。
scsetup コマンドを実行します。
メインメニューが表示されます。
# scsetup |
4 (デバイスグループとボリューム) を選択して、デバイスグループで作業を行います。
「デバイスグループメニュー」が表示されます。
6 (ディスクグループのキープロパティを変更) を選択して、デバイスグループの重要なプロパティを変更します。
「デバイスグループのプロパティ変更メニュー」が表示されます。
1 (preferenced または failback プロパティを変更) を選択して、デバイスグループのプロパティを変更します。
指示に従って、デバイスグループの preferenced および failback オプションを設定します。
ディスクデバイスグループの属性が変更されたことを確認します。
次のコマンドを実行し、表示されるデバイスグループ情報を確認します。
# scconf -p |
次に、scsetup でディスクデバイスグループ (dg-schost-1) の属性値を設定したときに生成される scconf コマンドの例を示します。
# scconf -c -D name=dg-schost-1,nodelist=phys-schost-1:phys-schost-2,\ preferenced=true,failback=enabled,numsecondaries=1 # scconf -p | grep デバイス デバイスグループ名: dg-schost-1 デバイスグループのタイプ: SDS デバイスグループの有効なフェイルバック: yes デバイスグループのノードリスト: phys-schost-1, phys-schost-2 デバイスグループの順序つきノードリスト: yes デバイスグループの希望のセカンダリ数: 1 デバイスグループのディスクセット名: dg-schost-1 |
デバイスグループの二次ノードのデフォルト数は 1 に設定されます。 この設定は、主ノードに障害が発生した場合にデバイスグループの主ノードの所有者となることができる、デバイスグループ内のノード数を指定します。 二次ノードの希望数の値には、1 からデバイスグループ内の主ノード以外のプロパイダノード数までの任意の整数を設定できます。
numsecondaries プロパティが変更されたとき、二次ノードの実際数と希望数の間に整合性がない場合、二次ノードはデバイスグループに追加されるか、またはデバイスグループから削除されます。
この手順では、scsetup(1M) を使用して、Solstice DiskSuite/Solaris Volume Manager または VxVM ディスクデバイスグループの numsecondaries プロパティを設定または設定解除します。 デバイスグループを構成するときのディスクデバ イスグループのオプションについては、scconf_dg_rawdisk(1M)、scconf_dg_sds(1M)、scconf_dg_svm(1M)、および scconf_dg_vxvm(1M) を参照してください。
クラスタ内の任意のノード上でスーパーユーザーになります。
scsetup ユーティリティを実行します。
# scsetup |
メインメニューが表示されます。
4 (デバイスグループとボリューム) を選択して、デバイスグループで作業を行います。
「デバイスグループメニュー」が表示されます。
6 (デバイスグループのキープロパティ変更) を選択して、デバイスグループの重要なプロパティを変更します。
「デバイスグループのプロパティ変更メニュー」が表示されます。
2 (numsecondaries プロパティを変更) を選択して、二次ノードの希望数を変更します。
指示に従って、ディスクデバイスグループに構成したい二次ノードの希望数を入力します。 適切な値を入力すると、対応する scconf コマンドが実行され、ログが出力され、ユーザーは前のメニューに戻ります。
ディスクデバイスグループの属性が変更されたことを確認します。
次のコマンドを実行して、表示されるデバイスグループ情報を確認します。
# scconf -p |
次に、デバイスグループ (dg-schost-1) の二次ノードの希望数を構成するときに、scsetup によって生成される scconf コマンドの例を示します。 この例では、ディスクグループとボリュームは以前に作成されているものと想定しています。
# scconf -c -D name=phys-host-1,nodelist=phys-schost-1:phys-schost-2,phys-schost-3\ preferenced=true,failback=enabled,numsecondaries=1 # scconf -p | grep デバイス デバイスグループ名: dg-schost-1 デバイスグループのタイプ: SDS/SVM デバイスグループの有効なフェイルバック: yes デバイスグループのノードリスト: phys-schost-1, phys-scost-2, phys-schost-3 デバイスグループの順序つきノードリスト: yes デバイスグループの希望のセカンダリ数: 1 デバイスグループのディスクセット名: dg-schost-1 |
次に、ヌル文字列値を使用して、二次ノードのデフォルト数を構成する例を示します。 デバイスグループは、デフォルト値が変更されても、デフォルト値を使用するように構成されます。
# scconf -c -D name=diskgrp1, nodelist=host1:host2:host3, preferenced=false,failback=enabled,numsecondaries= # scconf -p | grep デバイス デバイスグループ名: dg-schost-1 デバイスグループのタイプ: SDS/SVM デバイスグループの有効なフェイルバック: yes デバイスグループのノードリスト: phys-schost-1, phost-2, phys-schost-3 デバイスグループの順序つきノードリスト: yes デバイスグループの希望のセカンダリ数: 1 デバイスグループのディスクセット名: dg-schost-1 |
構成の一覧を表示するために、スーパーユーザーになる必要はありません。
ディスクデバイスグループ構成情報の一覧を表示するには、次の 3 つの方法があります。
scconf(1M) を使用して、ディスクデバイスグループ構成の一覧を表示
% scconf -p |
scstat -D コマンドを使用すると、次の情報が表示されます。
-- デバイスグループのサーバー -- デバイスグループ プライマリ セカンダリ ------------ ------- --------- デバイスグループのサーバー: phys-schost-2 - - デバイスグループのサーバー: phys-schost-1 phys-schost-2 phys-schost-3 デバイスグループのサーバー: phys-schost-3 - - -- デバイスグループの状態 -- デバイスグループ 状態 ------------ ------ デバイスグループの状態: phys-schost-2 オフライン デバイスグループの状態: phys-schost-1 オフライン デバイスグループの状態: phys-schost-3 オフライン |
scconf コマンドを使用するときは、ディスクグループ名の下に表示される情報を確認してください。
# scconf -p ... デバイスグループ名: dg-schost-1 デバイスグループのタイプ: SDS/SVM デバイスグループの有効なフェイルバック: yes デバイスグループのノードリスト: phys-schost-2, phys-schost-3 デバイスグループのディスクセット名: dg-schost-1 |
次の手順は、アクティブでないデバイスグループを起動する (オンラインにする) ときにも使用できます。
SunPlex Manager GUI を使用すると、アクティブでないデバイスグループをオンラインにしたり、デバイスグループの主ノードを切り替えることができます。 詳細については、SunPlex Manager のオンラインヘルプを参照してください。
クラスタ内の任意のノード上でスーパーユーザーになります。
scswitch(1M) を使用して、ディスクデバイスグループの主ノードを切り替えます。
# scswitch -z -D disk-device-group -h node |
切り替えを実行します。
切り替えるデバイスグループを指定します。
切り替え先のノードの名前を指定します。 このノードが新しい主ノードになります。
ディスクデバイスグループが新しい主ノードに切り替わったことを確認します。
ディスクデバイスグループが適切に登録されている場合、次のコマンドを使用すると、新しいディスクデバイスグループの情報が表示されます。
# scstat -D |
次に、ディスクデバイスグループの主ノードを切り替えて変更結果を確認する例を示します。
# scswitch -z -D dg-schost-1 -h phys-schost-1 # scstat -D -- デバイスグループのサーバー -- デバイスグループ プライマリ セカンダリ ------------ ------- --------- デバイスグループのサーバー: dg-schost-1 phys-schost-1 phys-schost-2 -- デバイスグループの状態 -- デバイスグループ 状態 ------------ ------ デバイスグループの状態: dg-schost-1 オンライン |
デバイスグループを保守状態にすることによって、デバイスのいずれかにアクセスされたときに、デバイスグループが自動的にオンラインになることを防ぎます。 デバイスグループを保守状態にする必要があるのは、修理手順において、修理が終わるまで、すべての入出力活動を停止する必要がある場合などです。 また、デバイスグループを保守状態にすることによって、別のノード上のディスクセットまたはディスクグループを修復していても、当該ノード上のディスクデバイスグループはオンラインにならないため、データの損失を防ぎます。
デバイスグループを保守状態にする前に、そのデバイスへのすべてのアクセスを停止し、依存するすべてのファイルシステムをマウント解除する必要があります。
デバイスグループを保守状態にします。
# scswitch -m -D disk-device-group |
修理手順を実行するときに、ディスクセットまたはディスクグループの所有権が必要な場合は、ディスクセットまたはディスクグループを手動でインポートします。
Solstice DiskSuite/Solaris Volume Manager の場合:
# metaset -C take -f -s diskset |
Solstice DiskSuite/Solaris Volume Manager ディスクセットの所有権を取得する場合、デバイスグループが保守状態にあるときは、metaset -C take コマンドを使用する必要があります。 metaset -t を使用すると、所有権の取得作業の一部として、デバイスグループがオンラインになります。 VxVM ディスクグループをインポートする場合、ディスクグループをインポートするときは、-t フラグを使用する必要があります。 こうすることによって、当該ノードが再起動した場合に、ディスクグループが自動的にインポートされることを防ぎます。
VERITAS Volume Manager の場合:
# vxdg -t import disk-group-name |
必要な修理手順をすべて実行します。
ディスクセットまたはディスクグループの所有権を解放します。
ディスクデバイスグループを保守状態から戻す前に、ディスクセットまたはディスクグループの所有権を解放する必要があります。 解放しないと、データを損失する可能性があります。
Solstice DiskSuite/Solaris Volume Manager の場合:
# metaset -C release -s diskset |
VERITAS Volume Manager の場合:
# vxdg deport disk-group-name |
ディスクデバイスグループをオンラインにします。
# scswitch -z -D disk-device-group -h node |
次に、ディスクデバイスグループ dg-schost-1 を保守状態にして、修理作業後に保守状態から戻す例を示します。
[ディスクデバイスグループを保守状態にする] # scswitch -m -D dg-schost-1 [必要に応じてディスクセットまたはディスクグループを手動でインポートする] For Solstice DiskSuite/Solaris Volume Manager の場合 : # metaset -C take -f -s dg-schost-1 For VERITAS Volume Manager の場合 : # vxdg -t import dg1 [必要な修理作業がすべて完了する] [所有権を開放する] For Solstice DiskSuite/Solaris Volume Manager の場合 : # metaset -C release -s dg-schost-1 For VERITAS Volume Manager の場合 : # vxdg deport dg1 [ディスクデバイスグループをオンラインにする] # scswitch -z -D dg-schost-1 -h phys-schost-1 |
クラスタファイルシステムは、クラスタのどのノードからでも読み取りやアクセスが可能な広域的なファイルシステムです。
表 4–3 Task Map: クラスタファイルシステムの管理
目次 |
参照箇所 |
---|---|
Sun Cluster の初期インストールの後で、クラスタファイルシステムを追加 - newfs(1M) と mkdir を使用します。 | |
クラスタファイルシステムを削除 - fuser(1M) と umount(1M)を使用します。 | |
ノード間で一貫性を保つように、クラスタ内の広域マウントポイントを検査 - sccheck(1M) を使用します。 |
次の作業は、Sun Cluster の初期インストール後に作成するクラスタファイルシステムごとに実行します。
必ず、正しいディスクデバイス名を指定してください。 クラスタファイルシステムを作成すると、ディスク上のデータはすべて消去されます。 デバイス名を誤って指定すると、本来消去する必要のないデータを失うことになります。
クラスタファイルシステムを追加するには以下が必要です。
クラスタ内の任意のノードでのスーパーユーザー特権。
ボリュームマネージャソフトウェアがクラスタ上にインストールおよび構成されていること。
クラスタファイルシステムの作成先がデバイスグループ (Solstice DiskSuite/Solaris Volume Manager デバイスグループまたは VxVM デバイスグループ)、またはブロックディスクスライスであること。
SunPlex Manager を使用してデータサービスをインストールした場合は、1 つ以上のクラスタファイルシステムがすでに自動的に作成されています (十分な共有ディスクが存在する場合)。
クラスタ内にある任意のノード上でスーパーユーザーになります。
ファイルシステムを迅速に作成するには、ファイルシステムを作成する広域デバイスの現在の主ノードでスーパーユーザーになります。
newfs コマンドを使用してファイルシステムを作成します。
newfs コマンドは、新しい UFS ファイルシステムを作成するときだけ有効です。 新しい VxFS ファイルシステムを作成する場合は、VxFS マニュアルの手順に従ってください。
# newfs raw-disk-device |
次の表に、引数 raw-disk-device の名前の例を挙げます。 命名規約はボリューム管理ソフトウェアごとに異なるので注意してください。
表 4–4 raw ディスクデバイス名の例
使用中のボリューム管理ソフトウェア |
使用可能なディスクデバイス名 |
説明 |
---|---|---|
Solstice DiskSuite/Solaris Volume Manager |
/dev/md/oracle/rdsk/d1 |
oracle メタセット内部の raw ディスクデバイス d1 |
SPARC: VERITAS Volume Manager |
/dev/vx/rdsk/oradg/vol01 |
oradg ディスクグループ内部の raw ディスクデバイス vol01 |
なし |
/dev/global/rdsk/d1s3 |
ブロックスライス d1s3 の raw ディスクデバイス |
クラスタ内の各ノードで、クラスタファイルシステムのマウントポイントディレクトリを作成します。
クラスタファイルシステムにアクセスしないノードがある場合でも、マウントポイントは各ノードごとに必要です。
管理を行いやすくするには、マウントポイントを /global/device-group ディレクトリに作成します。 これを使用することによって、広域に利用できるクラスタファイルシステムを、ローカルファイルシステムから簡単に判別できるようになります。
# mkdir -p /global/device-group/mountpoint |
デバイスが含まれるデバイスグループ名に対応するディレクトリ名を指定します。
クラスタファイルシステムのマウント先のディレクトリ名を指定します。
クラスタ内にある各ノード上で、/etc/vfstab ファイルにマウントポイント用のエントリを追加します。
以下の必須マウントオプションを使用します。
ロギングはすべてのクラスタファイルシステムに必要です。
Solaris UFS ロギング – global,logging マウントオプションを使用します。 UFS マウントポイントの詳細については、mount_ufs(1M) のマニュアルページを参照してください。
syncdir マウントオプションは UFS クラスタファイルシステムには必要ありません。 syncdir を指定すると、POSIX に準拠したファイルシステムの動作が保証されます。 指定しない場合は、UFS ファイルシステムと同じ動作になります。 syncdir を指定しない場合、ディスクブロックを割り当てる (つまり、データをファイルに追加するような) 書き込みの性能が大幅に向上します。 ただし、場合によっては syncdir を指定しないと、ファイ ルを閉じるまで容量不足の状態を検出できません。 syncdir を指定しないことで生じる問題はほとんどありません。 syncdir (つまり、POSIX の動作) を指定した場合、空間不足状態はファイルを閉じる前に見つかります。
Solstice DiskSuite/Solaris Volume Manager トランスメタデバイスまたはトランザクションボリューム– global マウントオプションを使用します (logging マウントオプションを使用してはいけません)。 トランスメタデバイスとトランザクションボリュームを設定する方法については、Solstice DiskSuite/Solaris Volume Manager のマニュアルを参照してください。
将来の Solaris リリースでは、トランザクションボリュームは Solaris オペレーティング環境から削除される予定です。 Solaris 8 リリースからサポートされている Solaris UFS ロギングは、トランザクションボリュームと同じ機能を備えており、より高い性能を提供します。UFS ロギングでは、システム管理の要件やオーバーヘッドが軽減されます。
VxFS ロギング – global および log マウントオプションを使用します。 詳細は、VxFS ソフトウェアに付属の mount_vxfs のマニュアルページを参照してください。
クラスタファイルシステムを自動的にマウントするには、mount at boot フィールドを yes に設定します。
各クラスタファイルシステムで、/etc/vfstab エントリの情報が各ノードで同じになるようにします。
各ノードの /etc/vfstab ファイルのエントリに、デバイスが同じ順序で表示されることを確認します。
ファイルシステムの起動順の依存関係を検査します。
たとえば、phys-schost-1 がディスクデバイス d0 を /global/oracle にマウントし、phys-schost-2 がディスクデバイス d1 を /global/oracle/logs にマウントすると仮定します。 この構成では、phys-schost-1 が起動して /global/oracle をマウントした後にのみ、phys-schost-2 が起動して /global/oracle/logs をマウントできます。
詳細については、vfstab(4) のマニュアルページを参照してください。
クラスタ内にある任意のノード上の、マウントポイントが存在し、クラスタ内にあるすべてのノード上で /etc/vfstab ファイルのエントリが正しいことを確認します。
# sccheck |
エラーがない場合は何も表示されません。
クラスタ内にある任意のノードから、クラスタファイルシステムをマウントします。
# mount /global/device-group/mountpoint |
クラスタ内にある各ノード上で、クラスタファイルシステムがマウントされていることを確認します。
df または mount のいずれかのコマンドを使用し、マウントされたファイルシステムの一覧を表示します。
Sun Cluster 環境で VxFS クラスタファイルシステムを管理するには、管理コマンドは VxFS クラスタファイルシステムがマウントされている主ノードから実行する必要があります。
次に、Solstice DiskSuite/Solaris Volume Manager メタデバイス /dev/md/oracle/rdsk/d1 上に UFS クラスタファイルシステムを作成する例を示します。
# newfs /dev/md/oracle/rdsk/d1 ... [各ノード上で以下のコマンドを実行:] # mkdir -p /global/oracle/d1 # vi /etc/vfstab #device device mount FS fsck mount mount #to mount to fsck point type pass at boot options # /dev/md/oracle/dsk/d1 /dev/md/oracle/rdsk/d1 /global/oracle/d1 ufs 2 yes global,logging [保存し、終了する] [1 つのノード上で以下のコマンドを実行する:] # sccheck # mount /dev/md/oracle/dsk/d1 /global/oracle/d1 # mount ... /global/oracle/d1 on /dev/md/oracle/dsk/d1 read/write/setuid/global/logging/ largefiles on Sun Oct 3 08:56:16 2001 |
クラスタファイルシステムを削除するには、単に、そのクラスタファイルシステムのマウントを解除します。 データも削除する場合は、配下のディスクデバイス (またはメタデバイスかボリューム) をシステムから削除します。
クラスタファイルシステムは、scshutdown(1M) を実行してクラスタ全体を停止したときに、システム停止処理の一環として自動的にマウント解除されます。 shutdown を実行して単独でノードを停止したときはマウント解除されません。 なお、停止するノードが、ディスクに接続されている唯一のノードの場合は、そのディスク上のクラスタファイルシステムにアクセスしようとするとエラーが発生します。
クラスタファイルシステムをマウント解除するには以下が必要です。
クラスタ内の任意のノードでのスーパーユーザー特権。
ファイルシステムが使用中でないこと。 ファイルシステムが使用中と見なされるのは、ユーザーがファイルシステム内のディレクトリにアクセスしている場合や、プログラムがファイルシステム内のファイルを開いている場合です。 ユーザーやプログラムは、クラスタ内のどのノードでもアクセスできます。
クラスタ内にある任意のノード上でスーパーユーザーになります。
マウントされているクラスタファイルシステムを確認します。
# mount -v |
各ノードで、クラスタファイルシステムを使用中の全プロセスの一覧を表示し、停止するプロセスを判断します。
# fuser -c [ -u ] mountpoint |
ファイルシステムのマウントポイントとなっているファイルと、マウントされているファイルシステム内のファイルが表示されます。
(任意) 各プロセス ID のユーザーログイン名を表示します。
プロセスを停止するクラスタファイルシステムの名前を指定します。
各ノードで、クラスタファイルシステムのプロセスをすべて停止します。
プロセスは任意の方法で停止できます。 必要であれば、次のコマンドを使用して、クラスタファイルシステムに関係するプロセスを強制終了してください。
# fuser -c -k mountpoint |
クラスファイルシステムを使用している各ノードに SIGKILL が送信されます。
各ノードで、ファイルシステムを使用しているプロセスがないことを確認します。
# fuser -c mountpoint |
1 つのノードからファイルシステムをマウント解除します。
# umount mountpoint |
マウント解除するクラスタファイルシステムの名前を指定します。 クラスタファイルシステムがマウントされているディレクトリの名前や、ファイルシステムのデバイス名パスを指定できます。
(任意) /etc/vfstab ファイルを編集して、削除するクラスタファイルシステムのエントリを削除します。
この手順は、/etc/vfstab ファイルにこのクラスタファイスシステムのエントリがある各クラスタノードで実行してください。
(任意) ディスクデバイスグループ、メタデバイス、プレックスを削除します。
詳細については、ボリューム管理ソフトウェアのマニュアルを参照してください。
次に、Solstice DiskSuite/Solaris Volume Manager メタデバイス /dev/md/oracle/rdsk/d1 にマウントされている UFS クラスタファイルシステムを削除する例を示します。
# mount -v ... /global/oracle/d1 on /dev/md/oracle/dsk/d1 read/write/setuid/global/logging/largefiles # fuser -c /global/oracle/d1 /global/oracle/d1: 4006c # fuser -c -k /global/oracle/d1 /global/oracle/d1: 4006c # fuser -c /global/oracle/d1 /global/oracle/d1: # umount /global/oracle/d1 (各ノードごとに強調表示されているエントリを削除する:) # vi /etc/vfstab #device device mount FS fsck mount mount #to mount to fsck point type pass at boot options # /dev/md/oracle/dsk/d1 /dev/md/oracle/rdsk/d1 /global/oracle/d1 ufs 2 yes global,logging [保存し終了する] |
クラスタファイルシステム上のデータを削除するには、配下のデバイスを削除します。 詳細については、ボリューム管理ソフトウェアのマニュアルを参照してください。
sccheck(1M) ユーティリティーを使用して、/etc/vfstab ファイル内のクラスタファイルシステムのエントリの構文を確認します。 エラーがない場合は何も表示されません。
sccheck は、デバイスやボリューム管理コンポーネントに影響を及ぼすような変更 (クラスタファイルシステムの削除など) をクラスタ構成に加えたあとで実行します。
ディスクパス監視 (DPM) の管理コマンドを使用すれば、二次ディスクパス障害の通知を受け取ることができます。 この節では、ディスクパスの監視に必要な管理作業を行うための手順を説明します。 ディスクパス監視デーモンの概念については、『 Sun Cluster の概念 (Solaris OS 版)』の「重要な概念 - 管理とアプリケーション開発」を参照してください。 scdpm コマンドのオプションと関連するコマンドについては、scdpm(1M) のマニュアルページを参照してください。 ログに記録されたエラーについては、syslogd(1M) のマニュアルページを参照してください。
scgdevs または scdidadm コマンドを使ってノードに入出力デバイスを追加すると、監視を行なっていた監視リストにディスクパスが自動的に追加されます。 Sun Cluster コマンドを使ってノードからデバイスを削除すると、 ディスクパスは自動的に監視から除外されます。
目次 |
参照箇所 |
---|---|
scdpm コマンドを使ってディスクパスを監視する | |
scdpm コマンドを使ってディスクパスの監視を解除する | |
scdpm コマンドを使って、障害のあるディスクパスのステータスを出力する | |
scdpm -f コマンドを使って、ファイルからディスクパスを監視または監視解除する |
以下のセクションの各手順では、scdpm コマンドとディスクパス引数を使用します。 ディスクパス引数はノード名とディスク名からなります。 ただし、ノード名は必須ではありません。指定しないと、all が使用されます。 次の表に、ディスクパスの命名規約を示します。
広域ディスクパス名はクラスタ全体で一貫性があるため、ディスクパス名には広域名を使用することを強くお勧めします。 UNIX ディスクパス名には、クラスタ全体での一貫性がありません。 つまり、あるディスクの UNIX ディスクパスは、クラスタノードによって異なる可能性があります。 たとえば、 あるディスクパス名があるノードでは c1t0d0 、別のノードでは c2t0d0 となっている場合があります。 UNIX ディスクパス名を使用する場合は、scdidadm -L コマンドを使って UNIX ディスクパス名と広域ディスクパス名を対応付けてから DPM コマンドを実行してください。 詳細については、scdidadm(1M) のマニュアルページを参照してください。
名前型 |
ディスクパス名の例 |
説明 |
---|---|---|
広域ディスクパス |
phys-schost-1:/dev/did/dsk/d1 |
phys-schost-1 ノードでのディスクパス d1 |
all:d1 |
クラスタのすべてのノードでのディスクパス d1 |
|
UNIX ディスクパス |
phys-schost-1:/dev/rdsk/c0t0d0s0 |
phys-schost-1 ノードでのディスクパス c0t0d0s0 |
phys-schost-1:all |
phys-schost-1 ノードでのすべてのディスクパス |
|
すべてのディスクパス |
all:all |
クラスタのすべてのノードでのすべてのディスクパス |
この作業は、クラスタのディスクパスを監視するときに行います。
DPM は、Sun Cluster 3.1 5/03 ソフトウェア より前にリリースされたバージョンが動作するノードではサポートされません。 ローリングアップグレードが行われているときには DPM コマンドを使用しないでください。 すべてのノードをアップグレードしたら、DPM コマンドを使用する前にこれらのノードをオンラインにする必要があります。
クラスタ内にある任意のノード上でスーパーユーザーになります。
scdpm コマンドを使ってディスクパスを監視します。
# scdpm -m node:disk path |
node:disk path 引数の命名規則については、表 4–6 を参照してください。
ディスクパスが監視されているか確認します。
# scdpm -p node:all |
次の例では、単一ノードから schost-1:/dev/did/rdsk/d1 ディスクパスを監視します。 ディスク /dev/did/dsk/d1 へのパスを監視するのは、ノード schost-1 上の DPM デーモンだけです。
# scdpm -m schost-1:d1 # scdpm -p schost-1:d1 schost-1:/dev/did/dsk/d1 Ok |
次の例では、すべてのノードから schost-1:/dev/did/dsk/d1 ディスクパスを監視します。 DPM は、/dev/did/dsk/d1 が有効なパスであるすべてのノードで起動されます。
# scdpm -m all:/dev/did/dsk/d1 # scdpm -p schost-1:d1 schost-1:/dev/did/dsk/d1 Ok |
次の例では、デーモンが CCR からディスク構成を読み直し、監視されているディスクパスをそのステータスとともに出力します。
# scdpm -m all:all # scdpm -p all:all schost-1:/dev/did/dsk/d4 Ok schost-1:/dev/did/dsk/d3 Ok schost-2:/dev/did/dsk/d4 Fail schost-2:/dev/did/dsk/d3 Ok schost-2:/dev/did/dsk/d5 Unmonitored schost-2:/dev/did/dsk/d6 Ok |
ディスクパスの監視を解除する場合は、この手順を使用します。
DPM は、Sun Cluster 3.1 5/03 ソフトウェア より前にリリースされたバージョンが動作するノードではサポートされません。 ローリングアップグレードが行われているときには DPM コマンドを使用しないでください。 すべてのノードをアップグレードしたら、DPM コマンドを使用する前にこれらのノードをオンラインにする必要があります。
クラスタ内にある任意のノード上でスーパーユーザーになります。
監視を解除するディスクパスの状態を調べます。
# scdpm -p [all:] disk path |
指定したディスクパスの現在のステータスを示す詳細なリストを出力します。
監視されているすべてのディスクパスと監視されていないすべてのディスクパスを表示します。
各ノードで、適切なディスクパスの監視を解除します。
# scdpm -u node:disk path |
node:disk path 引数の命名規則については、表 4–6 を参照してください。
次の例では、schost-2:/dev/did/rdsk/d1 ディスクパスの監視を解除し、クラスタ全体のディスクパスの一覧とそのステータスを出力します。
# scdpm -u schost-2:/dev/did/rdsk/d1 # scdpm -p all:all schost-1:/dev/did/dsk/d4 Ok schost-1:/dev/did/dsk/d3 Ok schost-2:/dev/did/dsk/d4 Fail schost-2:/dev/did/dsk/d3 Ok schost-2:/dev/did/dsk/d1 Unmonitored schost-2:/dev/did/dsk/d6 Ok |
クラスタに障害のあるディスクパスを表示する場合は、次の手順を使用します。
DPM は、Sun Cluster 3.1 5/03 ソフトウェア より前にリリースされたバージョンが動作するノードではサポートされません。 ローリングアップグレードが行われているときには DPM コマンドを使用しないでください。 すべてのノードをアップグレードしたら、DPM コマンドを使用する前にこれらのノードをオンラインにする必要があります。
クラスタ内にある任意のノード上でスーパーユーザーになります。
全クラスタ内の障害のあるディスクパスを表示します。
# scdpm -p -F node:disk path |
node:disk path 引数の命名規則については、表 4–6 を参照してください。
次の例では、全クラスタ内の障害のあるディスクパスを表示します。
# scdpm -p -F [all:]all schost-1:/dev/did/dsk/d4 Fail schost-1:/dev/did/dsk/d3 Fail schost-2:/dev/did/dsk/d4 Fail schost-2:/dev/did/dsk/d3 Fail schost-2:/dev/did/dsk/d5 Fail schost-2:/dev/did/dsk/d6 Fail |
ファイルを使ってディスクパスを監視したり、その監視を解除する場合は、次の手順を使用します。 ファイルには、監視または監視解除するコマンドと、ノード名、ディスクパス名を指定します。 ファイルの各フィールドは、カラムで区切る必要があります。 形式は次の通りです。
syntax in command file: [u,m] [node|all]:<[/dev/did/rdsk/]d- | [/dev/rdsk/]c-t-d- | all> command file entry u schost-1:/dev/did/rdsk/d5 m schost-2:all |
DPM は、Sun Cluster 3.1 5/03 ソフトウェア より前にリリースされたバージョンが動作するノードではサポートされません。 ローリングアップグレードが行われているときには DPM コマンドを使用しないでください。 すべてのノードをアップグレードしたら、DPM コマンドを使用する前にこれらのノードをオンラインにする必要があります。
クラスタ内にある任意のノード上でスーパーユーザーになります。
ファイルを使ってディスクパスを監視します。
# scdpm -f filename |
クラスタのディスクパスとそのステータスを確認します。
# scdpm -p all:all |
次の例では、ファイルを使ってディスクパスを監視または監視解除します。
# scdpm -f schost_config # scdpm -p all:all schost-1:/dev/did/dsk/d4 Ok schost-1:/dev/did/dsk/d3 Ok schost-2:/dev/did/dsk/d4 Fail schost-2:/dev/did/dsk/d3 Ok schost-2:/dev/did/dsk/d5 Unmonitored schost-2:/dev/did/dsk/d6 Ok |