この章では、Solaris 2.6 用の Cluster Volume Manager (CVM) リリース 2.2.1 のインストール手順とリリース情報を示します。
この CVM リリースは Solaris 2.6 上でテスト済みであり、Solaris 2.6 を必要とします。
CVM は Veritas Volume Manager (VxVM) のクラスタ対応バージョンであり、Oracle Parallel Server 構成で使用できるように設計されています。
このマニュアルは『Sun StorEdge Volume Manager リリース情報』および『Sun StorEdge Volume Manager 導入の手引き』を補足するものです。SSVM についての一般的な情報は、Sun StorEdge Volume Manager 2.6 マニュアルセットを参照してください。
パッケージをインストールする前に、この章を通読してください。
この章の内容は次のとおりです。
Cluster Volume Manager に関連する諸機能については、第 2 章「Cluster Volume Manager」を参照してください。リリース 2.2.1 の新機能は、次のとおりです。
CVM は Sun StorEdgeTM A3000 と互換になりました。
Sun StorEdge A3000 を使用する前に、『Sun StorEdge Volume Manager リリース情報』(リリース 2.5 または 2.6) を参照し、Sun StorEdge A3000 での SSVM (および CVM) のインストール方法と使用法を確認してください。
CVM は 1 クラスタあたり最大 4 ノードをサポートするようになりました。ただし、共有ディスクグループが複数のノードで動作するためには、すべてのノードに物理接続された記憶装置が必要です。
Visual Administrator により CVM では次の機能を利用できます。
Visual Administrator のルートウィンドウでは、共有ディスクグループの表示ボタンは緑色の影の境界線で強調表示され、非共有ディスクグループと区別されます。モノクロモニターでは、共有ディスクグループボタンには灰色の影の境界線が付きます。
共有ディスクグループの表示ウィンドウでは、タイトルバーに「Shared Disk Group」と表示されます。カラーモニターでは、共有ディスクグループ表示の背景色は緑です。モノクロモニターでは、背景色に変化はありません。
ディスクグループは、アクティブなクラスタでクラスタ共有可能なものとして初期化することができます。このため、「Initialize Disk Group」フォームに「Shared disk group:」フィールドがあり、「Yes」または「No」に設定できるようになっています。「Yes」に設定した場合、そのディスクグループは初期化と同時にクラスタ共有可能なものとして定義されます。システム管理者は、クラスタ共有可能なディスクグループのメンバーとして指定されたディスクが、クラスタを形成するホスト群から物理的にアクセスできるようにしておく必要があります。
ディスクグループは Visual Administrator を通じて共有されるものとして取り込むことができます。このため、「Import Disk Group」フォームに「Shared disk group:」フィールドがあり、「Yes」または「No」に設定できるようになっています。「Yes」に設定した場合、そのディスクグループはクラスタ共有可能なものとして取り込まれます。この操作は、取り込みを行うホスト上でクラスタがアクティブである場合にのみ有効です。管理者は、共有ディスクグループのすべてのディスクがすべてのホストから物理的にアクセスできるようにしておく必要があります。共有ディスクグループのすべてのディスクをアクセスできないホストは、クラスタに結合できません。
この節では、CVM をインストールまたはアップグレードする方法を説明します。CD-ROM で提供されるパッケージは、Solaris 2.6 を実行するシステムにインストールできます。CVM 2.2.1 は Sun Cluster 2.2 ソフトウェアを必要とします。Sun Cluster 2.2 のインストールまたはアップグレードを終了してから、CVM 2.2.1 をインストールしてください。
CVM のインストールは次の 2 段階で行います。
システムへの統合パッケージのインストール。「初めて CVM をインストールする場合」または 、「CVM リリース 2.2.1 にアップグレードする場合」を参照してください。
CVM の構成と設定。「rootdg の作成」および「共有ディスクの構成」を参照してください。
CVM を初めてインストールする場合は、『Sun StorEdge Volume Manager 導入の手引き』でインストール前の諸事項の確認を行なってください。
CVM のインストールに使用するほとんどのコマンドは、/sbin または /usr/sbin ディレクトリにあります。これらのディレクトリを PATH 環境変数に追加してください。
Bourne シェル (sh または ksh) を使用する場合は、次のコマンドを使用してください。
PATH=/sbin:/usr/sbin:$PATH export PATH |
C シェル (csh または tcsh) を使用する場合は、次のコマンドを使用してください。
setenv PATH /sbin:/usr/sbin:${PATH} |
CVM を使用するシステムには、ルートディスクグループ (rootdg) を含めて 1 つ以上のディスクグループがあります。rootdg は必須であり、システム間で共有することはできません。CVM の実行中は rootdg 内に少なくとも 1 つのディスクが存在する必要があります。CVM をインストールする前に、クラスタ内の各ノードの rootdg をどこに配置するかを決定する必要があります。
「rootdg の作成」の説明に従ってルートディスクをカプセル化することにより、rootdg を作成できます。インストールを開始する前に、共有ディスクグループの配置を決定する必要があります。1 つ以上の共有ディスクグループを設定します。
CVM を ダーティーリージョンログ (DRL) と併用する場合は、このログ用にディスク上の領域を確保してください。ログサイズは、ボリュームサイズとノード数に比例します (各ログには、ノードごとに 1 つの回復マップと 1 つのアクティブマップがあります)。
2 ノードクラスタでボリュームサイズが 2G バイトの場合、ログサイズとしては 5 ブロック (マップごとに 1 ブロック) が必要です。ボリュームサイズが 2G バイト増えるごとに、ログサイズはマップごとに約 1 ブロックの割合で増やす必要があります (したがって 2 ノードで ボリュームサイズが 4G バイトの場合、ログサイズは 10 ブロックとなる)。ログサイズの上限は 96 ブロックです。ボリュームサイズが大きくなるに従い、DRL はログサイズの上限を超えない範囲で、サイズの増加に応じてログの詳細の程度を変更します。4 ノードクラスタの場合は、より大きなログが必要となります。ログサイズについての詳細は、「ダーティーリージョンログと CVM」を参照してください。
CVM を SPARCstorageTM Array と併用する場合は、ファームウェアレベル 3.4 以上を使用する必要があります。
CVM は Solaris 2.6 を必要とします。したがって CVM をインストールする前に動作環境をアップグレードしなければならない場合があります。
CVM 2.2.1 CD-ROM をマウントします。
/cdrom にマウントされたファイルシステムとして CVM 2.2.1 が表示されます。
CVM パッケージのあるディレクトリに移動します。
# cd /cdrom/cdrom0/CVM_2_2_1/Product |
pkgadd コマンドを使用して次のパッケージをインストールします。
# pkgadd -d . SUNWvxvm SUNWvxva SUNWvmman SUNWvmdev |
各パッケージは上記の順序でインストールする必要があります。
「rootdg の作成」を参照し、CVM のインストールを続行します。
Sun Cluster 2.2 で動作する CVM リリース 2.2.1 は Solaris 2.6 を必要とするため、動作環境も同時にアップグレードしなければならない場合があります。推奨される手順としては、必要に応じて動作環境を最初にアップグレードし、次に Sun Cluster 2.2 のインストールまたはアップグレードを行い、最後に CVM をアップグレードします。
ディスクをカプセル化している場合は、手順 6までを実行し、それから動作環境のアップグレードを行う必要があります。
Sun Cluster 2.0 または 2.1 をインストールしている場合には、次の手順で CVM ソフトウェアと動作環境をアップグレードしてください。
動作環境をアップグレードするのに十分な領域が /opt にあることを確認します。
ボリューム上に /、/usr、/var、/opt のいずれかのファイルシステムを定義している場合、それらの各ボリュームの少なくとも 1 つのプレックスが、シリンダ境界で始まる 1 つのサブディスクから形成されていることを確認します。
上記は必須の作業です。アップグレードプロセスの一部分として、直接接続ディスクパーティションを使用するボリューム上にファイルシステムを一時的に配置する処理が含まれます。Solaris オペレーティング環境では、ディスクパーティションがシリンダ境界で始まることが要求されます。この変換は、アップグレードスクリプトによって必要に応じて自動的に処理されます。アップグレードスクリプトによって何らかの問題 (シリンダ境界への不整列など) が検出されると、問題点の説明が表示され、アップグレードプロセスが停止します。
CVM 2.2.1 CD-ROM をマウントします。
/cdrom にマウントされたファイルシステムとして CVM 2.2.1 が表示されます。
upgrade_start スクリプトを実行し、CVM の旧リリースを削除する準備をします。
# /cdrom/cdrom0/CVM_2_2_1/Tools/scripts/upgrade_start |
upgrade_start スクリプトによってファイルシステムを含むボリュームが検索されます。特定の重要なファイルシステムをパーティションを使用するように戻す必要があれば、その変換はスクリプトによって処理されます。
ボリュームマネージャパッケージを削除します。
phys-hahost1# pkgrm SUNWvmdev SUNWvmman SUNWvxva SUNWvxvm |
マシンを停止します (uadmin 2 0 などのコマンドを使用)。
(省略可能) 必要な場合、オペレーティング環境を Solaris 2.6 にアップグレードします。
Solaris ソフトウェア環境のアップグレード方法については、Solaris のインストール関連のマニュアルを参照してください。
(CVM CD-ROM 上で) CVM パッケージのあるディレクトリに移動します。
# cd /cdrom/cdrom0/CVM_2_2_1/Product/ |
pkgadd コマンドを使用して次のパッケージをインストールします。
# pkgadd -d . SUNWvxvm SUNWvxva SUNWvmman SUNWvmdev |
次のように入力してアップグレードを終了します。
# /cdrom/cdrom0/CVM_2_2_1/Tools/scripts/upgrade_finish |
マルチユーザーモードで再起動します。
この時点でアップグレード前の構成が有効となり、ボリューム上に以前定義されていたファイルシステムが定義およびマウントされた状態となります。
「rootdg の作成」を参照し、CVM のインストールを続行します。
CVM ソフトウェアの読み込みが完了したら、次にデフォルトのディスクグループ rootdg を作成する必要があります。1 つの方法として、カプセル化プロセスを使用してルートディスクを CVM の制御下に置く方法があります。カプセル化の結果として作成されたディスクグループは、rootdg ディスクグループになります。ただし、このパッケージを頻繁にアップグレードすることが予測される場合には、ルートディスクがカプセル化されていると、新バージョンにアップグレードする作業やエラーから回復する作業が難しくなるため、この方法では不都合な場合があります。ルートディスクをカプセル化しない場合は、vxinstall を使用して他のいずれかディスクをカプセル化し、(CVM を起動するために必要な) rootdg を作成することができます。もう 1 つの方法として、(共有せずカプセル化していないディスクのパーティション上に) 単純なボリュームマネージャディスクを作成し、それを rootdg として使用する方法があります。
この節では、カプセル化を使用してルートディスクグループを作成する方法を説明します。Sun では単純なディスクを使用する方法は推奨しません。rootdg を作成したら、「共有ディスクの構成」に進んでください。
ルートディスクをカプセル化するには、次の手順で rootdg を作成してください。
vxinstall を起動し、『Sun StorEdge Volume Manager 2.6 導入の手引き』で説明されているカスタムインストールの手順に従って、ルートディスクだけをカプセル化します。
他のディスクについては、すべて「Leave these disks alone」オプションを選択します。
vxinstall を使用してルートディスクをカプセル化したら、システムを再起動します。
vxinstall コマンドによって rootdg が自動的に作成されます。
CVM を初めてインストールする場合、または既存のクラスタにディスクを追加する場合には、新しい共有ディスクを構成する必要があります。CVM をアップグレードする場合には、共有ディスクが存在することを確認してください。
共有ディスクの構成は、1 つのノードからのみ行うようにしてください。ディスクを共有するかどうかは CVM ソフトウェアでは判断できないため、どれが共有ディスクかをユーザーが指定する必要があります。
構成作業の実行中は、他のノードから共有ディスクをアクセスしないよう注意してください。
CVM の旧リリースを CVM 2.2.1 にアップグレードする場合は、共有ディスクグループが存在するかどうかを確認してください。
すべてのノードでクラスタを起動します。
すべてのノードで次のコマンドを入力します。
# vxdg list |
この結果、以前存在していた共有ディスクグループが表示されます。CVM の旧バージョンで作成された DRL ログは、CVM 2.2.1 には小さすぎる場合があります。詳細については 「ダーティーリージョンログと CVM」を参照してください。
SEVM 2.x を CVM 2.2.1 にアップグレードし、既存のディスクグループを共有する場合は、次の手順で共有ディスクを構成してください。
少なくとも 1 つのノードでクラスタを起動します。
2 ノードクラスタの場合は、1 つのノードでクラスタを起動します。4 ノードクラスタの場合は、3 つのノードでクラスタを起動します。
すべてのディスクグループを一覧表示します。
# vxdg list |
共有するディスクグループをデポートします。
# vxdg deport groupname |
共有するディスクグループをインポートします。
# vxdg -s import groupname |
この結果、共有ディスクグループが共有済みとしてマークされ、それらにクラスタ ID が付けられ、他のノードが共有ディスクを認識できるようになります。
ダーティーリージョンログを使用している場合は、それらのログが有効であることを確認してください。有効でない場合は、より大きいログに交換してください。
すべての共有ディスクグループについて共有フラグを表示します。
# vxdg list |
以上でディスクグループが共有可能な状態になりました。
クラスタが 1 つのノードだけで動作している場合は、他のクラスタノードを起動します。
各ノードで準備が整ったら、vxdg list コマンドを入力します。
以前に表示されたものと同じ共有ディスクグループが一覧表示されます。
CVM を初めてインストールし設定する場合は、次のように共有ディスクを構成してください。
少なくとも 1 つのノードでクラスタを起動します。クラスタに複数のノードが含まれる場合は、手順 3 と 4 はマスターノードでのみ実行してください。CVM の動作モードは、vxdctl -c mode により表示できます。
vxdisksetup を実行して、ノード上の個々の共有ディスクを初期化します。その後、すべてのノードで vxdctl enable を実行します。
構成情報をディスクごとに格納しない場合、または、より大きい領域を使用してこの情報を格納する場合には、vxdisksetup を使用してディスクを選択できます。
共有ディスク上にディスクグループを作成します。
この作業は vxdg または Visual Administrator を使用して行うことができます。共有ディスクグループを作成するには、vxdg に -s オプションを指定します。
ディスクグループ内にボリュームを作成します。
この作業は vxassist または Visual Administrator を使用して行うことができます。ボリュームの型は gen である必要があります。RAID5 ボリュームは作成しないでください。
ログ用のサブディスクを作成する前に、「ダーティーリージョンログと CVM」を参照してください。
クラスタが 1 つのノードだけで動作している場合は、他のクラスタノードを起動します。
各ノードの準備が整ったら、vxdg list コマンドを入力します。以前に表示されたものと同じ共有ディスクグループが一覧表示されます。
この節の内容は、2 ノード構成にのみ適用されます。
Sun Cluster は障害防止の手段として、1 つのノードだけがアクティブのとき共有ディスクを予約します。その結果、アクセスを許可されていないクラスタ外のホストによる共有ディスクのアクセスが防止されます。この状況のとき、クラスタから切り離されたノード上でコマンド vxdisk list を実行すると、このようなコントローラ上のすべてのディスクが error 状態と表示される可能性があります。vxdisk のより詳細なオプションを使用すると、フラグ unavailable が表示されます。このクラスタに新しいノードが結合されると、Sun Cluster ソフトウェアはコントローラを解放します。CVM はこれらのディスクのアクセスを試み、成功した場合、ディスクは online 状態に戻ります。1 つのシステムが起動したとき、他のシステムがディスクを予約していた場合には、起動側のシステムにはディスクが見えない可能性があり、vxdisk を実行しても共有ディスクがまったく表示されない可能性があります。システムがクラスタに結合されると、共有ディスクが見えるようになります。
CVM 2.2.1 に関して、次の使用上の問題点が判明しています。
ディスクグループがディスクにアクセスできなくなったことにより、CVM がそのディスクグループをデポートした場合、そのディスク (クラスタ内のノードに依然として接続されている) を再びアクセスできるようにする唯一の方法は、そのディスクグループを強制的にインポートすることです。しかし、この状況で強制インポートを実行すると、ミラーの同期が失われ、どのミラーに正しいデータがあるかを判定できなくなる可能性があります。
物理的に共有されているディスク上に、個人用 (非共有) のディスクグループを配置することは可能です。ただし、これらのディスクが障害防止用に指定された (たとえば、Sun Cluster によって予約された) コントローラ上に存在する場合、個人用ディスクグループの所有者は、そのコントローラがクラスタに結合されていない場合はディスクグループにアクセスできません。
CVM は現在 RAID5 ボリュームをサポートしていません。
共有ディスクグループでは gen ボリュームタイプだけがサポートされています。fsgen ボリュームを使用するとシステムデッドロックの原因となる可能性があります。
クリーンシャットダウンまたは異常終了が原因で一方のノードがクラスタを切り離した場合、残ったノードはクラスタの再構成を実行します。この再構成が完了しないうちに、切り離したノードがクラスタに再び結合しようとした場合、その結果は切り離したノードがスレーブまたはマスターのどちらであるかによって異なります。
切り離したノードがスレーブの場合は、再結合は失敗し、次のいずれかのエラーメッセージが表示されます。
Resource temporarily unavailable [vxclust] return from cluster_establish is configuration daemon error -1 Resource temporarily unavailable master has disconnected |
後で再試行すれば、正常に結合できます。
切り離したノードがマスターの場合は、両方のノードでディスク関連のエラーメッセージが表示され、もう一方のノードが異常終了します。結合中のノードは最終的にクラスタに結合し、マスターになります。
マスターおよびスレーブノードの両方で vxconfigd が停止し、先にスレーブで再起動した場合、vxconfigd がマスターで起動されスレーブが再接続するまで (約 30 秒かかる場合がある)、vxconfigd が表示する情報は正しくありません。特に、共有ディスクグループは「disabled」と表示され、それらに関する情報はまったく提供されません。したがって、先にマスターで vxconfigd を起動する必要があります。
クラスタからノードが異常終了した場合、I/O がアクティブでない共有ディスクグループ上のオープン状態のボリュームデバイスは、それらのボリュームが閉じられるまで除去されません。これらのボリュームが引き続きオープンのとき、このノードがマスターとしてクラスタに結合する場合、これらのボリュームの存在によって特に問題になることはありません。ただし、ノードがスレーブとしてクラスタに再結合しようとすると失敗し、次のエラーメッセージが表示されます。
cannot assign minor # |
同時に、次のコンソールメッセージも表示されます。
WARNING:minor number ### disk group group in use |
現在のディスクのホットスペア機構は、ディスクの「部分的な」故障時にはうまく動作しません。この機能は、ディスクは部分的ではなく全体的に故障し、部分的なエラーは障害が発生したセクターを書き直すことによって修正できるという前提に基づいて作成されているからです。通常はこの前提で問題ありませんが、いくつかのセクターだけで障害が発生しホットスペアが作用しなかった事例が報告されています。
vxconfigd が停止し再起動されたとき、それによって大きなディスクグループ (たとえば数百のボリュームを含むディスクグループ) が使用不可になる場合があります。
回避策: vxconfigd を cleartempdir オプション付きで再起動します。必要ならディスクグループをデポートし、再度インポートしてからすべてのボリュームを起動してください。
ある種の状況では、ノードの異常終了が障害を引き起こす可能性があります。このような状況はほとんど発生しませんが、入出力を適切なときに停止できず、データの整合性を保証するためノードを停止させる必要がある場合に、発生する可能性があります。