Sun Cluster 2.2 のシステム管理

ボリュームマネージャの管理

この付録では、Solstice DiskSuite のディスクセットとメタデバイス、および Sun StorEdge Volume Manager と Cluster Volume Manager のオブジェクトを管理する方法について説明します。この付録に示す作業は、ボリューム管理ソフトウェアによって異なります。

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

Sun Cluster 環境での Solstice DiskSuite の使用

この節では、Solstice DiskSuite による次に示すデバイスの管理について説明します。

ディスクセット
ディスクセット内のディスク
多重ホストメタデバイス
ローカルメタデバイス

Solstice DiskSuite オブジェクトの管理についての詳細は、Solstice DiskSuite のマニュアルを参照してください。

メタデバイスとディスクセットの管理

メタデバイスとディスクセットは、Solstice DiskSuite のコマンド行ユーティリティ、または DiskSuite Tool (metatool(1M)) の GUI を使用して管理します。

Solstice DiskSuite のマニュアルを使用して Sun Cluster 構成内のディスクセットとメタデバイスを管理する場合は、あらかじめこの章の情報に目を通してください。

ディスクセットは、ディスクをグループにしたものです。ディスクセットの主な管理作業として、ディスクの追加と削除が挙げられます。

ディスクセットに含めたディスクを使用する前に、そのディスクのスライスを使用するメタデバイスを設定する必要があります。メタデバイスは、連結、ストライプ、ミラー、UFS ロギングデバイス (トランスデバイスとも呼ばれる) のどれかです。また、メタデバイスにエラーが発生した場合に代替デバイスとして機能する、スライスを含むホットスペアプールを作成することもできます。

注 -

メタデバイス名は、d から始まり、その後に番号が続きます。Sun Cluster 構成のデフォルトでは、128 (0 〜 127) の一意のメタデバイスが存在します。ユーザーが作成する各 UFS ロギングデバイスは、少なくても 7 つのメタデバイス名を使用します。したがって、大規模な Sun Cluster 構成では、128 を超えるデフォルトメタデバイス名が必要になることもあります。デフォルトの数を変更する方法については、Solstice DiskSuite のマニュアルを参照してください。ホットスペアプール名は、hsp で始まり、その後に番号が続きます。使用できるホットスペアプールは、最高 1000 (hsp000 〜 hsp999) です。

ディスクセットについて

この節では、ディスクセットの概要、ディスクセットと論理ホストとの関係の概要、論理ホストに対応するディスクセットにディスクの追加と削除を行う方法について説明します。

Sun Cluster の論理ホストは、物理ホストにマスターされます。論理ホストのディスクセットにアクセスできるのは、論理ホストをマスターしている物理ホストだけです。物理ホストが論理ホストのディスクセットをマスターする場合、そのディスクセットの所有権があると言います。ディスクセットの所有権は、通常、Sun Cluster によって管理されます。しかし、論理ホストが保守状態 (hastat(1M) コマンドで報告される) の場合は、DiskSuite の metaset -t コマンドを使用して、ディスクセットの所有権を手動で取得できます。論理ホストをサービスに戻す前に、metaset -r コマンドを使用してディスクセットの所有権を解放してください。

注 -

論理ホストが稼動している場合は、metaset(1M) コマンドの -t (所有権を取得する) または -r (所有権を解放する) オプションによるディスクセット管理は行わないでください。これらのオプションは Sun Cluster ソフトウェアによって内部的に使用され、クラスタノード間で調整されるべきものです。

ディスクセットへのディスクの追加

ディスクセットに追加されるディスクがサブミラーとして使用される場合、ミラー化が行えるように、2 台の多重ホストディスク拡張装置で 2 つのディスクが使用できるようにする必要があります。ただし、ディスクがホットスペアとして使用される場合は、単一のディスクを追加できます。

ディスクセットにディスクを追加するには (Solstice DiskSuite)

ディスクにデータが存在しないことを確認します。

パーティションテーブルが作成し直され、ディスク上にメタデバイス状態データベースの複製の領域が割り当てられるため、この確認は必ず行なってください。

多重ホストディスク拡張装置にディスクデバイスを挿入します。

ディスク拡張装置のハードウェアマニュアルに示されたディスクの追加と取り外しの方法に従ってください。

ディスクセットにディスクを追加します。

コマンドの構文を次に示します。diskset には、ディスクの追加先であるディスクセットの名前を指定します。drive には、ディスクの DID 名を dN (Sun Cluster を新たにインストールする場合) または cNtYdZ (HA 1.3 からアップグレードする場合) の形式で指定します。
# metaset -s diskset -a drive

metaset(1M) コマンドでディスクセットにディスクを追加した後、scadmin(1M) コマンドを使用して、追加されたディスクに対してフェイルファストの予約と有効化を行います。
phys-hahost1# scadmin reserve drivename

ディスクセットからのディスクの削除

ディスクセットに含まれるディスクは、ディスク上のスライスがメタデバイスやホットスペアプールで使用中でないかぎり、任意の時点で削除できます。

ディスクセットからディスクを削除するには (Solstice DiskSuite)

metastat(1M) コマンドを使用して、メタデバイスまたはホットスペアとして使用されているスライスが存在しないことを確認します。

metaset(1M) コマンドを使用して、ディスクセットから目的のディスクを削除します。

このコマンドの構文を次に示します。diskset には、取り外す (障害が発生した) ディスクを含むディスクセットの名前を指定します。drive には、ディスクの DID 名を dN (Sun Cluster を新たにインストールする場合) または cNtYdZ (HA 1.3 からアップグレードする場合) の形式で指定します。
# metaset -s diskset -d drive
この処理は、構成のサイズとディスクの数に応じて 15 分以上かかります。

多重ホストメタデバイスの管理

次の節では、Sun Cluster の多重ホスト環境でのメタデバイスの管理と、単一ホスト環境での管理の違いについて述べます。

次の節では、特に記述がないかぎり、Solstice DiskSuite のマニュアルに示されている方法を使用できます。

注 -

Solstice DiskSuite のマニュアルの操作説明は、単一ホスト構成だけを対象としています。

次の節では、作業に使用する Solstice DiskSuite コマンド行プログラムについて説明しています。特に指示がないかぎり、これらの作業は metatool(1M) の GUI を使用しても行えます。metatool(1M) を実行する場合は、ディスクセット名を指定できるように -s オプションを使用してください。

メタデバイスの管理

「監視ユーティリティ」で説明しているように、メタデバイスを管理するには、操作中に起こるメタデバイスのエラーを絶えず監視する必要があります。

hastat(1M) によってディスクセットの問題が報告された場合は、metastat(1M) コマンドを使用してエラーが発生したメタデバイスを特定してください。

metastat(1M) または metatool(1M) を実行するには、ディスクセット名を指定できるように -s オプションを使用する必要があります。

注 -

メタデバイス構成を変更する場合は、その構成情報を保存しておいてください。metastat -p を使用して md.tab ファイル内の情報に似た出力を作成し、続いてその出力を保存してください。パーティション分割情報の保存については、「ディスクパーティション情報の保存 (Solstice DiskSuite)」を参照してください。

ディスクへのミラーの追加

ミラー化されたメタデバイスは、Sun Cluster の可用性の高いアプリケーションに使用されるロギング UFS ファイルシステムの一部として使用できます。

ディスクセットに含まれるディスク上のアイドル状態のスライスは、metainit(1M) コマンドを使用してメタデバイスに組み込むことができます。

ディスクセットのミラーの削除

Sun Cluster の可用性の高いデータベースアプリケーションは、ミラー化された raw メタデバイスを使用してデータベースを格納できます。これらのミラーについては、各論理ホストの dfstab.logicalhost ファイルや vfstab ファイルには示されていませんが、関連する Sun Cluster データベース構成ファイルには出現します。これらの構成ファイルのミラーは削除する必要があります。このためには、まず Sun Cluster データベースシステムがミラーを使用するのを停止します。続いて、metaclear(1M) コマンドを使用してミラーを削除します。

サブミラーのオフライン化

SPARCstorage Array を使用している場合は、SPARCstorage Array のディスクの交換または追加を行う前に、そのトレー上のメタデバイスをすべてオフラインにする必要があります。

対称構成では、2 つのディスクセットのそれぞれのディスクが SPARCstorage Array の同じトレーに存在する可能性があるため、保守のためにサブミラーをオフラインにするのは困難です。トレーを取り外す前に、各ディスクセットのメタデバイスをオフラインにする必要があります。

トレー内の各ディスクのサブミラーをすべてオフラインにするには、metaoffline(1M) コマンドを使用します。

新しいメタデバイスの作成

ディスクセットにディスクを追加した後、metainit(1M) または metatool(1M) を使用して新しいメタデバイスを作成してください。新しいデバイスがホットスペアの場合、metahs(1M) コマンドを使用して、ホットスペアプールにホットスペアを入れてください。

エラーが発生したコンポーネントの交換

エラーが発生したメタデバイスコンポーネントを交換するには、metareplace(1M) コマンドを使用します。

代替のスライス (またはディスク) は、使用可能な状態でなければなりません。これは、使用されていない既存のデバイスでも、ディスクセットに追加した新しいデバイスでもかまいません。

metareplace -e コマンドを使用して、(シャーシの停電などが原因の) 一時エラーが起きるドライブをサービスに戻すこともできます。

メタデバイスの削除

メタデバイスを削除する前に、Sun Cluster HA for NFS によって使用されているコンポーネントがメタデバイス内に存在しないことを確認してください。その後、metaclear(1M) コマンドを使用してメタデバイスを削除してください。

メタデバイスの拡張

メタデバイスを拡張するには、別々の多重ホストディスク拡張装置で少なくても 2 つのスライス (ディスク) が使用できるようにする必要があります。新しい 2 つのスライスはそれぞれ、metainit(1M) コマンドを使用して別々のサブミラーに追加します。続いて、growfs(1M) コマンドを使用してファイルシステムを拡張できます。

注意 -

growfs(1M) コマンドの実行中、クライアントサービスが停止する場合があります。

ファイルシステムを拡張している間にテイクオーバーが発生すると、ファイルシステムは拡張されません。テイクオーバーが終了した後で、growfs(1M) コマンドを再実行する必要があります。

注 -

/logicalhost/statmon が含まれるファイルシステムの拡張は行えません。statd(1M) プログラムはこのディレクトリを変更するため、ファイルシステムの拡張が行われている間は長時間ブロックされます。このため、ネットワークファイルのロックプロトコルに予測できない影響が出る場合があります。これは、Sun Cluster HA for NFS を使用した構成だけの問題です。

ホットスペアプールの管理

ホットスペアデバイスは、それらが使用中でないかぎり、いつでもスペアプールに追加または削除できます。また、新しいスペアプールを作成し、metahs(1M) コマンドを使用してそれらをサブミラーに関連付けることができます。

UFS ログの管理

多重ホストディスク上の UFS ログはすべてミラー化されます。サブミラーに障害が発生すると、そのサブミラーはエラーが発生したコンポーネントとして報告されます。サブミラーの障害は、metareplace(1M) または metatool(1M) を使用して修復してください。

UFS ログが入ったミラー全体に障害が発生した場合は、ファイルシステムのマウントを解除します。次に、アクセス可能なデータのバックアップ、エラーの修復、ファイルシステムの修復 (fsck(1M) を使用) を行います。その後ファイルシステムをマウントし直す必要があります。

論理ホストへの UFS ロギングの追加

フェイルオーバーまたは haswitch(1M) タイムアウトの基準を満たすため、論理ホスト内の UFS ファイルシステムは、すべてロギング UFS システムでなければなりません。ロギング UFS システムにより、高速のスイッチオーバーとテイクオーバーが容易になります。

ロギング UFS ファイルシステムは、ミラー化されたロギングデバイスと UFS マスターファイルシステムを使用して、トランスデバイスを作成することにより設定します。ロギングデバイスと UFS マスターデバイスは共にミラー化する必要があります。

通常、ディスクセット内の各ドライブのスライス 6 は、UFS ログとして使用できます。スライスは、UFS ログサブミラーに使用できます。スライスが希望するログサイズよりも小さい場合は、複数のスライスを連結できます。通常、UFS ログには 100M バイトあたり 1M バイトが適切です (最大 64M バイト)。ログスライスのドライブが、UFS マスターデバイスのドライブと異なることが理想的です。

注 -

UFS ログ用の領域を確保するためにディスクのパーティション分割を再度行う必要がある場合は、シリンダ 0 から始まる最低 2M バイトの既存のスライス 7 を保持してください。スライス 7 は、メタデバイス状態データベースの複製に必要な領域として予約されています。Tag と Flag フィールドは (format(1M) コマンドで報告されるように)、スライス 7 用に保持する必要があります。Tag と Flag フィールドは、最初の構成が確立されると、metaset(1M) コマンドにより正しく設定されます。

トランスデバイスが構成された後で、newfs(1M) を使用してトランスデバイス上に UFS ファイルシステムを作成してください。

newfs 処理が終了した後、次の方法に従って論理ホストの vfstab ファイルに UFS ファイルシステムを追加してください。

/etc/opt/SUNWcluster/conf/hanfs/vfstab.logicalhost ファイルを編集して、管理情報と多重ホスト UFS ファイルシステム情報を更新します。

すべてのクラスタノードの vfstab.logicalhost ファイルに同じ情報が入っていることを確認してください。クラスタ内のすべてのノードで vfstab.logicalhost ファイルを同時に編集するには、cconsole(1) 機能を使用してください。

次に、管理ファイルシステムとその他 4 つの UFS ファイルシステムの情報が入った vfstab.logicalhost ファイルの例を示します。

#device                 device                   mount       FS  fsck  mount mount
 #to mount                to fsck                    point       type pass  all   options#
 /dev/md/hahost1/dsk/d11  /dev/md/hahost1/rdsk/d11 /hahost1    ufs  1     no   -
 /dev/md/hahost1/dsk/d1   /dev/md/hahost1/rdsk/d1  /hahost1/1  ufs  1     no   -
 /dev/md/hahost1/dsk/d2   /dev/md/hahost1/rdsk/d2  /hahost1/2  ufs  1     no   -
 /dev/md/hahost1/dsk/d3   /dev/md/hahostt1/rdsk/d3 /hahost1/3  ufs  1     no   -
 /dev/md/hahost1/dsk/d4   /dev/md/hahost1/rdsk/d4  /hahost1/4  ufs  1     no   -

ファイルシステムが Sun Cluster HA for NFS によって共有される場合は、『Sun Cluster 2.2 ソフトウェアのインストール』の Sun Cluster HA for NFS についての章で説明されている、NFS ファイルシステムを共有する方法に従ってください。

新しいファイルシステムは、メンバーシップモニターの次の再構成時に自動的にマウントされます。メンバーシップの再構成を強制するには、次のコマンドを使用してください。

# haswitch -r

ローカルメタデバイスの管理

ローカルディスクはミラー化できます。一方のミラーに障害が発生した場合は、Solstice DiskSuite のマニュアルに示された方法でそのミラーを交換し、新たに追加したディスクと正常なディスクとの同期をとり直してください。

サポートされていない (障害を起こす) メタデバイスアクション

次のメタデバイスアクションは、Sun Cluster 構成でサポートされていません。

ディスクセットに片方向ミラーを作成する
ローカルディスクに、わずかなメタデバイス状態データベース複製を使用して構成を作成する
このマニュアルまたは Sun Cluster の別のマニュアルに明記されている場合を除いて、多重ホストディスクでメタデバイス状態データベースの複製を変更する

Sun Cluster 環境での SSVM と CVM の使用

Sun StorEdge Volume Manager (SSVM) と Cluster Volume Manager (CVM) は、同じボリュームマネージャをもとにした製品です。CVM は、Oracle Parallel Server (OPS) 構成でだけ使用されます。この節では、ボリュームマネージャの制御下にあるディスクを使用して次のオブジェクトを管理する方法について説明します。

ボリュームマネージャディスク
ディスクグループ
サブディスク
プレックス
ボリューム

これらのオブジェクトの管理の詳細は、該当する節を参照してください。

オブジェクト管理の概要 (SSVM と CVM)

ボリュームマネージャの制御下にあるオブジェクトは、コマンド行ユーティリティまたは Visual Administrator の GUI を使用して作成と管理を行います。

SSVM と CVM のマニュアルを使用して Sun Cluster 構成内でボリュームマネージャの制御下にあるオブジェクトを管理する場合は、あらかじめこの章の情報に目を通してください。ここに示す作業は、以下の作業を行うための方法の 1 つです。実際の構成に最も適した方法を使用してください。

これらのオブジェクトは、通常、次のような関係を持ちます。

ディスクはボリュームマネージャに制御され、ディスクグループとしてグループ化される
サブディスク (それぞれはディスクの特定の部分にあたる) は、プレックス (ミラー) を形成するように結合される
ボリュームは、1 つ以上のプレックスから構成される

デフォルトのディスクグループは rootdg (ルートディスクグループ) です。必要に応じて、さらにディスクグループを作成できます。ディスクグループの主な管理作業として、ディスクの追加と削除が挙げられます。

ディスクグループに含めたディスクを使用する前に、物理ディスクのスライスを使用して (ボリュームマネージャ制御下の) ディスクとサブディスクを設定することにより、プレックス (ミラー) を構築する必要があります。プレックスは、連結またはストライプです。

SSVM と CVM では、アプリケーションは、スライスではなく (ボリュームマネージャディスクに作成された) ボリュームにアクセスします。

次の節では、作業に使用する SSVM と CVM のコマンド行プログラムについて説明しています。特に指示がないかぎり、これらの作業はすべて GUI を使用しても行えます。

注 -

Sun Cluster HA データサービスを使用しているノードでは、ディスクグループの論理ホストが保守モードにないかぎり、Sun Cluster の制御下にあるディスクグループに対して vxdg import または deport オプションを手動で実行しないでください。ディスクグループを手動でインポートまたはデポートする前に、ディスクグループを制御できるすべてのノードで scadmin stopnode を実行してそれらのノードの Sun Cluster を停止するか、haswitch -m コマンドを使用して対応するすべての論理ホストを保守モードに切り替える必要があります。ディスクグループの制御を Sun Cluster に戻す用意ができた時点で、ディスクグループをデポートし、その後 scadmin startnode または haswitch(1M) を実行して論理ホストを Sun Cluster の制御下に置くのが最も安全な方法です。

ディスクについて

ディスクを SSVM または CVM で使用するには、ボリュームマネージャに制御されるディスクとしてあらかじめ識別 (初期化) する必要があります。初期化が正しく行われたディスクは、ディスクグループへの追加、障害のあるディスクの交換、新しいディスクグループの作成などに使用できます。

ディスクの初期化と構成を行うには (SSVM と CVM)

ディスクにデータが存在しないことを確認します。

ディスクが初期化されると既存のデータは完全に消去されるため、この確認は必ず行なってください。

付属のハードウェアマニュアルの操作指示に従って、ディスク格納装置にディスクデバイスを挿入し、取り付けます。

ディスクを初期化し、ディスクグループに加えます。

この作業は、通常、vxdiskadm メニューまたは GUI を使用して行います。また、コマンド行ユーティリティの vxdisksetup と vxdg addisk を使用して、ディスクの初期化とディスクグループへの追加を行うこともできます。

ディスクをオフラインにする

物理ディスクをオフラインにする必要が生じることがあります。ディスクが破損している場合は、無効にして取り外す必要があります。別のシステムに接続するために物理ディスクをほかの場所に移動する場合も、あらかじめディスクを無効にする必要があります。

物理ディスクをオフラインにするには、まずディスクグループからそのディスクを削除し、続いて vxdisk(1M) コマンドを使用してディスクをオフラインにします。

ディスクの削除

ディスクを別のシステムに移動させる場合や、ディスクが故障しかかっているか完全に故障した場合は、ディスクを削除することができます。また、不要になったボリュームも削除できます。

ディスクグループからディスクを削除するには、vxdg(1M) コマンドを使用します。プライベートパーティションとパブリックパーティションを削除してボリュームマネージャによるディスク制御を解除するには、vxdiskunsetup(1M) コマンドを使用します。これらのコマンドの詳細は、vxdg(1M) と vxdiskunsetup(1M) のマニュアルページを参照してください。

ディスクグループの管理

SSVM と CVM では、特定のディスクグループのデフォルトマスターであるアクティブノードからディスクグループの生成を行うのが最も便利です。N+1 構成では、これらのデフォルトマスターノードはそれぞれ、多重ホストディスクコネクティビティを、クラスタ内の 1 つのノードであるホットスタンバイノードとだけ共有します。これらのノードを使用してディスクグループを生成すると、不正に構成されたグループの作成を避けることができます。

ディスクグループを作成するには (SSVM と CVM)

新しいディスクグループは、vxdiskadm メニューまたは GUI を使用して作成できます。また、コマンド行ユーティリティ vxdg init も使用できます。

ディスクグループの生成が終わると、vxdg deport コマンドを使用して各ディスクグループをデポートする必要があります。続いて、-t オプションを使用して各グループをホットスタンバイノードにインポートします。-t オプションはインポートが次の起動まで持続することを防止するため、必ず指定してください。SSVM または CVM のプレックスとボリュームをすべて作成した後に、ボリュームを起動する必要があります。

ディスクを別のディスクグループに移動させるには (SSVM と CVM)

ディスクをディスクグループ間で移動させるには、ディスクグループからそのディスクを削除し、別のディスクグループに追加します。

次の例は、コマンド行ユーティリティを使用して、物理ディスク c1t0d1 をディスクグループ acct からディスクグループ log_node1 に移動させます。

vxprint(1M) コマンドを使用して、ディスクが使用中であるかどうかを確認します。

# vxprint -g acct
 TY NAME         ASSOC        KSTATE   LENGTH   PLOFFS   STATE    TUTIL0  PUTIL0
 dg acct         acct         -        -        -        -        -       -

 dm c1t0d0       c1t0d0s2     -        2050272  -        -        -       -
 dm c1t0d1       c1t0d1s2     -        2050272  -        -        -       -
 dm c2t0d0       c2t0d0s2     -        2050272  -        -        -       -
 dm c2t0d1       c2t0d1s2     -        2050272  -        -        -       -

 v  newvol       gen          ENABLED  204800   -        ACTIVE   -       -
 pl newvol-01    newvol       ENABLED  205632   -        ACTIVE   -       -
 sd c1t0d1-01    newvol-01    ENABLED  205632   0        -        -       -
 pl newvol-02    newvol       ENABLED  205632   -        ACTIVE   -       -
 sd c2t0d1-01    newvol-02    ENABLED  205632   0        -        -       -

 v  vol01        gen          ENABLED  1024000  -        ACTIVE   -       -
 pl vol01-01     vol01        ENABLED  1024128  -        ACTIVE   -       -
 sd c1t0d0-01    vol01-01     ENABLED  1024128  0        -        -       -
 pl vol01-02     vol01        ENABLED  1024128  -        ACTIVE   -       -
 sd c2t0d0-01    vol01-02     ENABLED  1024128  0        -        -       -

vxedit(1M) コマンドを使用してボリュームを削除し、c1t0d1 ディスクを解放します。

vxedit コマンドは、共有ディスクグループをマスターしている CVM ノードから実行する必要があります。
# vxedit -g acct -fr rm newvol
-f オプションは、操作を強制します。-r オプションは、操作を繰り返し実行します。

c1t0d1 ディスクを acct ディスクグループから削除します。

共有ディスクグループをマスターしている CVM ノードから、vxdg コマンドを実行してください。
# vxdg -g acct rmdisk c1t0d1

c1t0d1 ディスクを log_node1 ディスクグループに追加します。

# vxdg -g log_node1 adddisk c1t0d1

注意 -

この作業は、ディスク上に構成やデータを保存しません。

c1t0d1 が削除された後の acct ディスクグループの状態を次に示します。

# vxprint -g acct
TY NAME         ASSOC        KSTATE   LENGTH   PLOFFS   STATE    TUTIL0  PUTIL0
 dg acct         acct         -        -        -        -        -       -

 dm c1t0d0       c1t0d0s2     -        2050272  -        -        -       -
 dm c2t0d0       c2t0d0s2     -        2050272  -        -        -       -
 dm c2t0d1       c2t0d1s2     -        2050272  -        -        -       -

 v  vol01        gen          ENABLED  1024000  -        ACTIVE   -       -
 pl vol01-01     vol01        ENABLED  1024128  -        ACTIVE   -       -
 sd c1t0d0-01    vol01-01     ENABLED  1024128  0        -        -       -
 pl vol01-02     vol01        ENABLED  1024128  -        ACTIVE   -       -
 sd c2t0d0-01    vol01-02     ENABLED  1024128  0        -        -       -

c1t0d1 が追加された後の log_node1 ディスクグループの状態を次に示します。

# vxprint -g log_node1
 TY NAME         ASSOC        KSTATE   LENGTH   PLOFFS   STATE    TUTIL0  PUTIL0
 dg log_node1    log_node1    -        -        -        -        -       -

 dm c1t0d1       c1t0d1s2     -        2050272  -        -        -       -
 dm c1t3d0       c1t3d0s2     -        2050272  -        -        -       -
 dm c2t3d0       c2t3d0s2     -        2050272  -        -        -       -
 #

ボリュームのアクセス権または所有権を変更するには、vxedit コマンドを使用する必要があります。

注意 -

chmod と chgrp は使用しないでください。chmod または chgrp によって設定されるアクセス権と所有権は、再起動時に自動的に root に再設定されます。

変更前の /dev/vx/rdsk ディレクトリ内のボリューム vol01 と vol02 のアクセス権と所有権の例を次に示します。

# ls -l
crw-------		 	 1	 	root 	root	 nnn,nnnnn		 date	time 	vol01
crw-------		 	 1	 	root	 root 	nnn,nnnnn		date 	time 	vol02
 ...

vol01 のアクセス権と所有権を変更する例を次に示します。

# vxedit -g group_name set mode=755 user=oracle vol01

編集後にアクセス権と所有権がどのように変わったかを注意してください。

# ls -l
crwxr-xr-x		 	 1 	oracle	 root	 nnn,nnnnn	 	date 	time 	vol01
crw-------		 	 1	 root	 root	 nnn,nnnnn 		date 	time 	vol02
 ...

SSVM オブジェクトと CVM オブジェクトの管理

ボリューム (仮想ディスク) には、ファイルシステムやデータベースなどのアプリケーションを格納できます。ボリュームは、サブディスクを含むプレックス (最大 32) で構成されます。ボリュームを使用するためには、関連付けられた 1 つ以上のサブディスクに対応する 1 つ以上のプレックスが存在しなければなりません。ボリューム内のサブディスクはすべて、同じディスクグループに属する必要があります。

ボリュームの作成とボリュームへのミラーの追加

各ディスクグループのボリュームの作成と、各ボリュームに対応するミラーの作成には、GUI またはコマンド行ユーティリティ vxassist(1M) を使用してください。

SSVM デバイスまたは CVM デバイスの実際のサイズは、ディスクドライブ全体の容量よりもわずかに小さくなります。SSVM と CVM は、個人的な使用のための領域 (非共有領域と呼ばれる) を少量確保します。

注 -

異なるディスクグループにボリュームが属する場合は、同じボリューム名を使用することができます。

ダーティーリージョンログの追加

ダーティーリージョンログ (DRL) は、システム障害が発生した後に、ミラー化されたボリュームをすばやく回復させるために使用される、オプションのボリュームプロパティです。DRL は、ミラー化されたボリュームに対する I/O 書き込みが原因で変化した領域の記録をとり、この情報を使用して回復を要するボリュームの一部だけを回復させます。

既存のボリュームのログファイルの作成

ログサブディスクは、DRL が有効になっているボリュームの DRL を保存するために使用されます。DRL を使用するボリュームには、最低 1 つのログサブディスクが存在します (複数のログサブディスクを使用して DRL をミラー化できます)。各ログサブディスクは、ボリュームのプレックスの 1 つに対応しています。ログサブディスクは、プレックスあたり 1 つしか存在できません。プレックスにログサブディスクだけが含まれ、データサブディスクが含まれない場合、そのプレックスはログプレックスとして参照できます。ログサブディスクは、データサブディスクが入った通常のプレックスと関連付けることもできます。この場合、データサブディスクの 1 つに障害が発生したためにプレックスの切り離しが必要になると、ログサブディスクは使用できなくなる可能性があります。

既存のボリュームのログを作成するには、GUI またはコマンド行ユーティリティ vxassist(1M) を使用してください。

ホットリロケーション

ホットリロケーションは、冗長 (ミラー化または RAID5) ボリュームマネージャオブジェクトの I/O 障害に自動的に反応し、それらのオブジェクトの冗長性とアクセスを自動的に復元するシステム機能です。ホットリロケーションは、SSVM を使用した構成でのみサポートされます。SSVM は、ボリュームマネージャオブジェクトの I/O 障害を検出し、影響を受けたサブディスクをスペアディスクに指定されたディスクに再配置するか、ディスクグループ内の領域を解放します。続いて SSVM は、障害が発生する前に存在していたオブジェクトを再構築し、それらを冗長でアクセス可能な状態に戻します。

部分的なディスク障害 (ディスク上の一部のサブディスクにだけ影響する障害) が発生した場合、ディスクの障害部分に存在する冗長データは再配置され、影響がなかったディスク部分から構成される既存のボリュームは以前のままアクセスできます。

注 -

ホットリロケーションが行われるのは、障害が発生したディスク上の冗長 (ミラー化または RAID5) サブディスクに対してだけです。障害が発生したディスク上の非冗長サブディスクは再配置されませんが、それらの障害の通知は行われます。

スペアディスクを交換用として使用するには、あらかじめ初期化し、ディスクグループにスペアとして入れておく必要があります。障害発生時にスペアに指定されたディスクが存在しないと、SSVM は障害が発生したディスクグループ内の使用できる任意の空き領域を自動的に使用します。十分な空き容量がない場合には、スペア領域と空き領域が組み合わされて使用されます。各ディスクグループでは、vxedit(1M) コマンドを使用して 1 つ以上のディスクをホットリロケーションのスペアとして指定できます。

VxFS ファイルシステムの使用

タイプが fsgen であるボリューム上の、論理ホストのディスクグループに対応するファイルシステム (UFS または VxFS) は構成と指定が行えます。クラスタノードが論理ホストを制御する場合、ディスクグループに対応する、論理ホストのファイルシステムは制御側ノードの指定されたマウント先にマウントされます。

論理ホストの再構成作業が行われている間、fsck(1M) コマンドを使用してファイルシステムを検査する必要があります。この処理は UFS ファイルシステム上で非対話式の並列モードで行われますが、再構成作業の総合的な時間に影響を与える可能性があります。UFS、SDS、VxFS ファイルシステムのロギング機能は、ファイルシステムのマウントの前に fsck(1M) が使用する時間を大幅に短縮します。

ボリューム回復に加えてデータサービスのスイッチオーバーが必要な場合、回復は再構成にかかる時間よりも長くなります。この場合はタイムアウトし、ノードが停止します。

このため、ミラー化ボリュームを設定する場合は、システム障害時のボリューム回復時間を短縮するために必ず DRL ログを追加してください。クラスタ環境でミラー化ボリュームが使用されている場合は、500M バイトを超えるボリュームに DRL を割り当てる必要があります。

HA データサービスに 500M バイトを超える大きなファイルシステムが使用されている場合は、VxFS を使用してください。通常、VxFS は Sun Cluster には含まれていないため、Veritas 社から別途購入する必要があります。

注 -

非常に小さなミラー化ファイルシステムを使用して論理ホストを構成することも可能ですが、ファイルシステムのサイズが増えるにつれてタイムアウトが発生する可能性があるため、ダーティーリージョンログ (DRL) または VxFS ファイルシステムを使用することをお勧めします。

ファイルシステムの拡張

ファイルシステムが含まれるストライプ化されたボリュームまたは RAID5 ボリュームを拡張するには、そのボリュームに現在存在するディスクと同じ数のディスク上に空き領域がなければなりません。たとえば、一緒にストライプ化された 4 つの 1G バイトディスク (4G バイトファイルシステム 1 つ) が存在し、1G バイトの容量を追加する場合 (5G バイトのファイルシステムを作成する)、少なくても 0.25G バイトの空き領域をそれぞれ持つ 4 つの新しいディスクが必要です。つまり、1 つのディスクを 4 ディスク構成のストライプに追加することはできません。

SSVM または SSVM の GUI は、ファイルシステムを拡張するディスクを選択します。ファイルシステムを拡張させる特定のディスクを選択するには、コマンド行インタフェースを使用してください。

UFS ファイルシステムを直接縮小することは不可能ですが、ボリュームを作成し直し、そのボリュームに対して newfs を実行し、その後バックアップからデータを復元すれば縮小されたファイルシステムができます。

ローカルミラーの管理

ローカルディスクはミラー化できます。一方のミラーに障害が発生した場合は、ボリュームマネージャのマニュアルで説明されている方法に従って、障害が発生したミラーを交換し、新たに追加したディスクと正常なディスクの同期をとり直してください。

Solstice Backup による多重ホストデータのバックアップ

この節では、Solstice Backup^TM を使用して Sun Cluster ファイルシステムをバックアップする方法について説明しています。

Solstice Backup は、単一のサーバーでサーバーソフトウェアの各コピーを実行するように設計されています。Solstice Backup は、ファイルのバックアップ元と同じ物理ディスクを使用してファイルの回復が行われることを想定します。

Solstice Backup は、サーバーとクライアントに対応する物理マシンについての多くのデータ (ホスト名とホスト ID) を保持しています。論理ホストが構成される実際の物理マシンに関するこれらの情報は、Solstice Backup がクライアントインデックスをどのように格納するかに影響を与えます。

Solstice Backup の /nsr データベースは、多重ホストディスクに格納しないでください。2 つの Solstice Backup サーバーが同じ /nsr データベースにアクセスを試みると、衝突が起きます。

Solstice Backup は、クライアントインデックスを一定の方法で格納します。そのため、別の日に個別の Solstice Backup サーバーを使用して個々のクライアントをバックアップすることは避けてください。バックアップを行う場合は必ず、その論理ホストが常に同じ物理サーバーによってマスターされていることを確認してください。これは、将来の回復作業を円滑に行うためです。

注 -

デフォルトでは、Sun Cluster システムはバックアップ構成の詳しいファイルシステムの一覧を生成しません。保存セットの一覧にキーワード All が含まれる場合、どのファイルシステムを保存すべきか決定するために、/etc/vfstab ファイルが検査されます。Sun Cluster の vfstab ファイルはデフォルトでは /etc/opt/SUNWcluster/conf/hanfs に保持されるため、保存する Sun Cluster ファイルシステムを明示的に指定しないかぎり、Solstice Backup はそれらを見つけることができません。バックアップ作業のテストを行う場合、バックアップを要するすべての Sun Cluster ファイルシステムが、Solstice Backup ファイルシステム一覧に含まれることを確認してください。

次に、Solstice Backup を構成するための 4 つの方法を示します。使用している Sun Cluster 構成に応じて、適切な方法を選択してください。この場合、スイッチオーバーの回数も考慮してください。方法を決定したら、将来の回復作業が円滑に行われるように、以降は同じ方法でバックアップを行なってください。

構成方法を次に示します。

Solstice Backup サーバーとして構成された非クラスタノード (可用性が高くないサーバー) を使用する

Sun Cluster サーバーとは別のサーバーを Solstice Backup サーバーとして機能するように構成し、論理ホストをこのサーバーのクライアントとして構成します。最良の結果を出すには、日常のバックアップを行う前に、論理ホストがそれらの個々のデフォルトマスター上に構成されていることを必ず確認してください。この方法では、スイッチオーバーが必要になる場合があります。Solstice Backup は、クライアントインデックスを一定の方法で格納します。そのため、テイクオーバーなどの結果、論理サーバーの制御を別々の日に複数の代替サーバーによって行うと、回復操作時に Solstice Backup の混乱を引き起こす場合があります。
ローカルバックアップを行うように構成された 1 台の Sun Cluster サーバーを使用する

ローカルバックアップを行うように Sun Cluster サーバーの 1 台を構成します。日常のバックアップを行う前に、必ず論理ホストをこの Solstice Backup サーバーに切り替えます。たとえば、phys-hahost1 と phys-hahost2 が Sun Cluster サーバーで、phys-hahost1 が Solstice Backup サーバーの場合、バックアップを行う前に必ず論理ホストを phys-hahost1 に切り替えます。バックアップ終了後、通常 phys-hahost2 にマスターされている論理ホストをスイッチバックします。
Solstice Backup サーバーとして構成された複数の Sun Cluster サーバーを使用する

デフォルトで制御する論理ホストのローカルバックアップを行うように、各 Sun Cluster サーバーを構成します。日常のバックアップを行う前に、必ず論理ホストがそれらの個々のデフォルトマスター上で構成されていることを確認してください。この方法では、スイッチオーバーが必要になる場合があります。Solstice Backup は、クライアントインデックスを一定の方法で格納します。そのため、テイクオーバーなどの結果、論理サーバーの制御を別の日に複数の代替サーバーによって行うと、回復操作時に Solstice Backup の混乱を引き起こす場合があります。
Solstice Backup サーバーとして構成された 1 台の Sun Cluster サーバーを使用する

論理ホストをローカルにバックアップし、その兄弟の論理ホストをネットワークを介してバックアップするように 1 台の Sun Cluster サーバーを構成します。日常のバックアップを行う前に、必ず論理ホストがそれらの個々のデフォルトマスター上で構成されていることを確認してください。この方法では、スイッチオーバーが必要になる場合があります。Solstice Backup は、クライアントインデックスを一定の方法で格納します。そのため、テイクオーバーなどの結果、論理サーバーの制御を別々の日に複数の代替サーバーによって行うと、回復操作時に Solstice Backup の混乱を引き起こす場合があります。

上記の 4 つのバックアップ方法はすべて、指定した Solstice Backup サーバーがダウンしている場合に一時的にバックアップを行う別のサーバーを構成できます。一時的な Solstice Backup サーバーを使用して、通常の Solstice Backup サーバーによってバックアップされたファイルを回復させることはできません。また、通常のバックアップサーバーから、一時的なサーバーによってバックアップされたファイルを回復させることもできません。