test

Sun Cluster 2.2 ソフトウェアのインストール

計画の作業

この節では、構成の計画に関係する作業と問題点について説明します。これらの作業を示されている順序通りに行う必要はありませんが、構成計画の一環としてすべての説明を参照してください。

管理ワークステーションの計画

アクティブクラスタを管理するための専用の SPARCTM ワークステーション (「管理ワークステーション」と呼ぶ) を使用するかどうかを決定する必要があります。管理ワークステーションは、クラスタのノードではありません。管理ワークステーションは、端末集配信装置に対する telnet セッションを実行して、コンソールのログインを容易に行える SPARC マシンであれば何でもかまいません。また、Sun Enterprise 10000 プラットフォームでは、管理ワークステーションから netcon コマンドを使用してシステムサービスプロセッサ (SSP) にログインし、接続する必要があります。

Sun Cluster は専用の管理ワークステーションを必要としませんが、専用の管理ワークステーションを使用することには、次の利点があります。

注 -

1 つのクラスタノードを管理ワークステーションとクラスタノードの両方の目的に使用できます。このためには、クラスタノードを「クライアント」と「サーバー」の両方としてインストールする必要があります。

名前と命名規則の設定

クラスタを構成する前に、次の項目の名前を決定する必要があります。

ネットワークインタフェース名 (および関連付けられた IP アドレス) は、各パブリックネットワーク上のすべての論理ホストに必要です。一定の命名規則を使用する必要はありませんが、このマニュアルでは、推奨する命名規則として次の命名規則を使用します。付録 A 「構成ワークシートと構成例」 の構成ワークシートを利用してください。

クラスタ - 構成作業の一貫として、クラスタ名の指定が求められます。任意の名前を選択できます。Sun Cluster には、クラスタ名に関する制限はありません。

物理ホスト - 物理ホスト名は、論理ホスト名に接頭辞 phys- を付けることによって作成します (物理ホストはそれぞれ論理ホストを 1 つだけマスターします)。たとえば、hahost1 という名前の論理ホストをマスターする物理ホストの名前は、phys-hahost1 とします。Sun Cluster には、複数の論理ホストをマスターする物理ホストに対する命名規則あるいはデフォルト名はありません。

注意 - 注意 -

ネームサービスとして DNS を使用する場合は、物理ホスト名や論理ホスト名に下線 (_) を使用しないでください。DNS は、下線を含むホスト名を認識しません。

論理ホストとディスクグループ - Sun Cluster では、論理ホストとディスクグループに異なる名前を付けることができます。しかし、同じ名前を使用することは、Sun Cluster の慣習であり、管理が容易になります。詳細は、「論理ホストの構成計画」を参照してください。

パブリックネットワーク - パブリックネットワーク上で物理ホストの識別に使用される名前は、主物理ホスト名です。二次パブリックネットワーク上で物理ホストの識別に使用される名前は、二次物理ホスト名です。図 2-1 で示すように、物理ホストには、次の規則に基づいて名前を付けてください。

注 -

主物理ホスト名は、uname -n によって返されるノード名です。

プライベートインターコネクト - プライベートインターコネクトに対するデフォルトの命名規則はありません。

図 2-1 に命名規則の例を示します。

図 2-1 パブリックネットワークとプライベートネットワークに対する命名規則

Graphic

ネットワーク接続の計画

ローカルエリアネットワークに少なくとも 1 つのパブリックネットワークを接続し、クラスタのノード同士を 2 つのプライベートインターコネクトで接続する必要があります。Sun Cluster ネットワーク構成の概要については第 1 章「Sun Cluster 環境について」、ネットワーク計画ワークシートについては付録 A 「構成ワークシートと構成例」 をそれぞれ参照してください。

パブリックネットワーク接続

パブリックネットワーク構成を計画するにあたっては、次のことを考慮してください。

プライベートネットワーク接続

Sun Cluster の通常の運用には、2 つのプライベートネットワークが必要です。プライベートネットワークに 100 M ビット/秒 Ethernet または 1G ビット/秒 SCI (Scalable Coherent Interface) 接続のどちらを使用するかを決定する必要があります。

2 ノードの構成では、パブリックネットワークは、クラスタノード間にポイントツーポイントケーブルを使用することによって実現できます。3 ノードまたは 4 ノードの構成では、ハブまたはスイッチを使用して実現します。プライベートネットワーク上を転送されるのは、Sun Cluster ノード間のプライベートトラフィックだけです。

SCI スイッチを使用してノードを接続する場合、各ノードは両方のスイッチの同じ番号のポートに接続する必要があります。インストール時には、スイッチのポート番号がノード番号に対応していることに注意してください。たとえば、ノード 0 は、スイッチのポート 0 に物理接続されたホストです。

クラス C のネットワーク番号 (204.152.64) は、Sun Cluster ノードによってプライベートネットワーク用に予約されています。同じネットワーク番号が、すべての Sun Cluster システムによって使用されます。

端末集配信装置と管理ワークステーションのネットワーク接続

端末集配信装置および管理ワークステーションは、Sun Cluster ノードにアクセスできるパブリックネットワークに接続します。端末集配信装置および管理ワークステーションに IP アドレスとホスト名を割り当て、パブリックネットワーク上のクラスタノードにアクセスできるようにする必要があります。

注 -

Sun Enterprise 10000 システムは、端末集配信装置ではなく、システムサービスプロセッサ (SSP) を使用します。SSP には、ホスト名と IP アドレス、root (スーパーユーザー) のパスワードを割り当てる必要があります。また、SSP 上に ssp という名前のユーザーを作成し、Sun Cluster のインストール時に、ユーザー ssp にパスワードを割り当てる必要があります。

Solaris オペレーティング環境のインストール計画

Sun Cluster ソフトウェアをインストールするには、同じバージョンの Solaris オペレーティング環境 (Solaris 2.6、Solaris 7 または Solaris 8) を使用して、クラスタ内のすべてのノードをインストールする必要があります。クラスタノードに Solaris をインストールするときは、この節で説明する一般的な規則に従ってください。

注 -

Sun Enterprise 10000 以外のプラットフォームには、少なくとも全体ディストリビューションをインストールする必要があります。Sun Enterprise 10000 システムには、全体ディストリビューションプラス OEM が必要です。

Solaris のインタフェースグループの無効化

Solaris 2.6 オペレーティング環境には、インタフェースグループという新機能が追加されています。この機能は、Solaris 2.6 ソフトウェアではデフォルトの動作として実装されていますが、以降のリリースでは、オプションです。

ifconfig(1M) のマニュアルページで説明しているように、論理または物理のいずれかのインタフェースと IP 接頭辞を共有する場合、1 つのインタフェースグループにまとめられます。発信元アドレスが指定されていない場合、IP はインタフェースグループを使用して、発信元アドレスを交替で選択します。同じグループに複数の物理インタフェースがある場合は、IP の宛先ごとに異なる IP アドレスにまたがってトラフィックを配信します (IP の宛先別の情報については、netstat(1M) を参照)。

インタフェースグループ機能を有効にすると、論理ホストのスイッチオーバーで問題が発生します。すなわち、RPC タイムアウトが発生して、スイッチオーバーで問題が発生し、論理ホストが現在のホスト上でマスターされたままになります。したがって、すべてのクラスタノードにおいて、インタフェースグループは無効にしてください。インタフェースグループの状態は、/etc/system ファイルの ip_enable_group_ifs の値によって決まります。

このパラメータの値は、次の ndd コマンドで確認できます。

# ndd /dev/ip ip_enable_group_ifs

値として 1 (有効) が返された場合は、/etc/system ファイルに次の行を追加することによって、インタフェースグループを無効にしてください。

set ip:ip_enable_group_ifs=0
注意 - 注意 -

/etc/system ファイルを編集した場合は、変更内容を有効にするために必ずシステムを再起動してください。

システムディスクのパーティション分割

Solaris をインストールすると、システムディスクは、ルート (/) や /usr、その他標準のファイルシステム用のスライスにパーティション分割されます。使用するボリュームマネージャに求められる条件を満たすには、このパーティション構成を変更する必要があります。この後の説明に従って、ディスク空間を割り当ててください。

ファイルシステム用スライス

ファイルシステムの見積りガイドラインについては、Solaris のマニュアルを参照してください。Sun Cluster によって、ファイルシステムスライスが追加で必要になることはありません。

ボリュームマネージャ用スライス

Solstice DiskSuite を使用する場合は、メタデバイス状態データベースの複製用としてシステムディスクに 10M バイトを確保する必要があります。複製についての詳細は、Solstice DiskSuite のマニュアルを参照してください。

VxVM を使用する場合は、ルートディスクグループ (rootdg) 用のディスクを指定する必要があります。rootdg の作成に関するガイドラインと詳しい説明は、VERITAS のマニュアルを参照してください。詳細は、「VERITAS Volume Manager に関する注意事項」を参照してください。

ルート (/) スライス

ローカルディスクのルート (/) スライスには、各種ファイルおよびディレクトリ用の領域のほかに、/devices のデバイス i ノードと /dev のシンボリックリンク用の領域も存在する必要があります。

また、ルートスライスには、以下を格納できる十分な大きさである必要があります。

注 -

Sun Cluster は、root プロセスを実行するさまざまなシェルスクリプトを使用します。このため、root ユーザー用の /.cshrc* および /.profile ファイルは空にしておくか、クラスタノードに存在しないようにします。

大量のディスクドライブで構成される場合は、大きなルートファイルシステムが必要になることがあります。

注 -

空き領域が不足した場合は、すべてのクラスタノードにオペレーティング環境を再インストールして、ルートスライス内の空き領域を追加する必要があります。ルートスライスの全空間の少なくとも 20% を空き領域として確保してください。

/usr、/var、/opt スライス

/usr スライスは、ユーザーファイルシステムを保持します。/var スライスは、システムログファイルを保持します。/opt スライスは、Sun Cluster とデータサービスソフトウェアパッケージを保持します。Solaris ソフトウェアをインストールするときの割り当て値の変更についての詳細は、『Solaris のインストール (上級編)』を参照してください。

ボリューム管理

Sun Cluster は、ボリューム管理ソフトウェアを使用して、ディスクをディスクグループにまとめ、1 つの単位で管理できるようにします。Sun Cluster は、Solstice DiskSuite、および VERITAS Volume Manager (VxVM) をサポートしています。Sun Cluster は、Oracle Parallel Server のデータサービスのために VERITAS Volume Manager のクラスタ機能をサポートします。

ボリューム管理ソフトウェアは、Solaris オペレーティング環境をインストールした後にインストールする必要があります。ただし Sun Cluster ソフトウェアの前または後のどちらにインストールしてもかまいません。ボリューム管理ソフトウェアのインストール方法については、使用するボリューム管理ソフトウェアのマニュアルと、このマニュアルの第 3 章「Sun Cluster ソフトウェアのインストールと構成」を参照してください。

ディスクを構成するにあたっては次のガイドラインに従ってください。

ボリューム管理に関係する推奨ディスク配置については、「ボリュームマネージャ用スライス」を参照してください。また、その他の制限事項については、使用するボリュームマネージャのマニュアルを参照してください。

Solstice DiskSuite に関する注意事項

Solstice DiskSuite の構成を計画するにあたっては、次のことを考慮してください。

VERITAS Volume Manager に関する注意事項

VxVM あるいは CVM の構成を計画するにあたっては、次のことを考慮してください。

注意 - 注意 -

ディスク空間とスライスが不足していると、後で起動ディスクのカプセル化が行えなくなります。また、オペレーティング環境の再インストールが必要になることがあるため、インストール時間が長くなることがあります。

注 -

SPARCstorage Array や Sun StorEdge A5000 以外の記憶装置に VERITAS Volume Manager を使用する場合は、VERITAS Volume Manager 用のライセンスが必要です。SPARCstorage Array と Sun StorEdge A5000 には、VxVM 用のライセンスが含まれています。必要な VxVM ライセンスについては、Sun License Center にお問い合わせください。詳細は、http://www.sun.com/licensing/ を参照してください。

Sun Cluster で Solstice DiskSuite を使用する場合、ライセンスは必要ありません。

ファイルシステムのロギング

高可用性システムの重要な特長の 1 つとして、ノードに障害が発生しても、すぐにファイルシステムをオンラインに戻せることが挙げられます。これは、ロギングファイルシステムを利用することによって行います。Sun Cluster は、VERITAS の VxFS ロギングと DiskSuite の UFS ロギング、Solaris の UFS ロギングの 3 つのロギングファイルシステムをサポートしています。Oracle Parallel Server (OPS) と組み合わせた場合、VERITAS Volume Manager のクラスタ機能は raw パーティションを使用するため、ロギングファイルシステムを使用しません。しかし、クラスタ内では、OPS と HA データサービスと一緒に VxVM のクラスタ機能を実行することができます。この構成では、OPS 共有ディスクグループは raw パーティションを使用しますが、HA ディスクグループが VxFS または Solaris UFS ロギングファイルシステムのいずれかを使用できます。上記の共存型の VxVM のクラスタ機能構成を除けば、Sun Cluster は、次の表に示すボリュームマネージャとロギングファイルシステムの組み合わせをサポートします。

表 2-1 サポートされるロギングファイルシステム

Solaris オペレーティング環境 

ボリュームマネージャ 

サポートされるファイルシステム 

Solaris 2.6 

VERITAS Volume Manager 

VxFS、UFS (ロギングなし) 

Solstice DiskSuite 

DiskSuite UFS ロギング 

Solaris 7 

Solstice DiskSuite 

DiskSuite UFS ロギング、Solaris UFS ロギング 

Solaris 8 

Solstice DiskSuite 

DiskSuite UFS ロギング、Solaris UFS ロギング 

VxVM は、ロギングファイルシステムが提供する機能に似た、ダーティリージョンログ (DRL) という機能を使用して、再起動後の高速回復の支援をします。VxVM のクラスタ機能については、VERITAS Volume Manager のマニュアルを、DiskSuite UFS ロギングについては、Solstice DiskSuite のマニュアルを参照してください。また、VxFS ロギングについては、VERITAS のマニュアルを参照してください。以下では、Solaris UFS ロギングについて簡単に説明します。詳細は、mount_ufs(1M) のマニュアルページを参照してください。

Solaris UFS ロギングは、Solaris 7 オペレーティング環境の新機能です。

Solaris UFS ロギングは循環ログを使用して、UFS ファイルシステムに加えられたあらゆる変更を記録します。ログが一杯になると、変更点は実際のファイルシステムに「ロールイン (取り込み)」されます。ロギングの利点は、UFS ファイルシステムが矛盾した状態、すなわち、処理が完了しない状態で残されないことです。システムがクラッシュした後、fsck には解決すべきことがないため、起動時間が短くなります。

Solaris UFS ロギングは、mount コマンドの「ロギング」オプションを使用して有効にします。UFS ファイルシステムに対してロギングを有効にするには、mount コマンドに -o logging オプションを追加するか、/etc/opt/SUNWcluster/conf/hanfs/vfstab.logicalhost のエントリ (右端のカラム) に「logging」という単語を追加します。

Solaris UFS ロギングは、常に UFS ファイルシステム上の空き領域を使用してログを確保します。1G バイトより小さいファイルシステムの場合、ログが占有する領域のサイズは 1M バイトです。より大きなファイルシステムの場合は、1G バイトあたり 1M バイトの割合で、最高 64M バイトを占有します。

Solaris UFS ロギングは、常にファイルシステムと同じディスク上にログファイルを書き込みます。このため、logging オプションを使用すると、ディスクサイズが制限されます。DiskSuite UFS ロギングでは、ログを別のディスクに置くことが可能であり、ログに関係する入出力を少し減らすのに役立ちます。

DiskSuite UFS ロギングでは、ロギングに使用されたトランスデバイスによってメタデバイスが作成されます。ただし、ログはミラー化やストライプ化が可能なメタデバイスです。Solstice DiskSuite では、最大 1T バイトのロギングファイルシステムを作成できます。

Solstice DiskSuite によってすでにロギングが提供されている場合、mount コマンドの logging オプションは機能しません。logging オプションを使用すると、すでにファイルシステムにロギングが提供されていることを示す警告メッセージが返されます。ログのサイズあるいは位置を制御する必要がある場合は、DiskSuite UFS ロギングを使用してください。

ファイルシステムの使用状況によっては、Solaris UFS ロギングを使用した方が、ロギングなしのときよりも性能が向上することがあります。

現在のところ、DiskSuite UFS ロギングから Solaris UFS ロギングへの変更はサポートされていません。

多重ホストディスク要件の決定

RAID5 構成を使用しない場合は、Sun Cluster 構成では、あらゆる多重ホストディスクをミラー化する必要があります。ミラー化することにより、構成は単一ディスク障害に耐えることができます。詳細は、「ミラー化に関するガイドライン」とボリューム管理ソフトウェアのマニュアルを参照してください。

Sun Cluster 構成に移動するデータ量を決定してください。RAID5 を使用しない場合は、決定した量を 2 倍にして、ミラー化のためのディスク空間を確保します。RAID5 では、1/(デバイス数 -1) に等しい空間がさらに必要になります。ディスク要件を計画するには、付録 A 「構成ワークシートと構成例」 のワークシートを使用してください。

ディスク要件を計画するにあたっては、次の点を考慮してください。

ディスク空間の拡張

ディスク空間の拡張を計画するときは、次のことを考慮してください。

ディスクドライブのサイズとディスクドライブ数

多重ホストディスク拡張装置では、異なるサイズのディスクを使用できます。どのサイズのドライブを使用するか決定するときは、次のことを考慮してください。

多重ホストディスク上のファイルシステム配置計画

Sun Cluster は、特定のディスク配置あるいはファイルシステムサイズを必要としません。ファイルシステム階層に求められる条件は、使用するボリューム管理ソフトウェアに依存します。

Sun Cluster は、ボリューム管理ソフトウェアに関係なく、1 つのディスクグループに、HA 管理ファイルシステムの役割を果たすファイルシステムを少なくとも 1 つ必要とします。 一般に、この管理ファイルシステムは、/logicalhost (logicalhost は、実際に使用している論理ホスト名) にマウントされ、最低でも 10M バイトの大きさである必要があります。管理ファイルシステムは、データサービスの構成情報を含むプライベートディレクトリの格納に使用されます。

Solstice DiskSuite を使用するクラスタの場合は、HA 管理ファイルシステムを含むメタデバイスを作成する必要があります。HA 管理ファイルシステムは、他の多重ホストファイルシステムと同じ構成にしてください。つまり、ミラー化して、トランスデバイスとして構成してください。

VxVM を使用するクラスタの場合は、Sun Cluster によって、dg-stat (dg は、ボリュームが作成されるディスクグループ名) というボリュームに HA 管理ファイルシステムが作成されます。通常、dg は、論理ホストを定義するときに指定するディスクグループリストの先頭のディスクグループ名です。

ファイルシステムサイズとディスク配置を計画するときは、次のことを考慮してください。

Solstice DiskSuite を含むファイルシステム

Solstice DiskSuite ソフトウェアは、多重ホストディスクに、他のボリュームマネージャでは必要とされない領域を必要とし、いくつか使用制限があります。たとえば、Solstice DiskSuite で UNIX ファイルシステム (UFS) ロギングを使用する場合は、各多重ホストディスクの 1 〜 2% をメタデバイス状態データベースの複製と UFS ロギング用に予約する必要があります。具体的なガイドラインと制限事項については、付録 B 「Solstice DiskSuite の構成」 と Solstice DiskSuite のマニュアルを参照してください。

それぞれの共有ディスクセットが使用するすべてのメタデバイスは前もって (すなわち、md.conf ファイルに含まれる設定に基づいて再構成起動時に) 作成されます。md.conf ファイル内の各フィールドについては、Solstice DiskSuite のマニュアルに説明があります。Sun Cluster 構成で使用するフィールドは 2 つあり、md_nsets と nmd です。md_nsets フィールドはディスクセット数を定義し、mnd フィールドは各ディスクセット用に作成するメタデバイス数を定義します。インストール時、これら 2 つのフィールドに、将来のクラスタのあらゆる拡張を考慮した値を設定してください。

クラスタを実際に使用し始めた後で Solstice DiskSuite の構成を拡張しようとすると、すべてのノードについて再構成再起動が必要になるため、作業は時間のかかるものになります。また、要求されたあらゆるデバイスを作成するには、ルート (/) ファイルシステムに確保された領域では不十分という危険性も伴います。

md_nsets フィールドには、クラスタ内の予想される論理ホスト数に 1 を加えた値を設定して、Solstice DiskSuite が論理ホストの全プライベートディスク (すなわち、ローカルディスクセットに含まれないメタデバイス) を管理できるようにしてください。

nmd フィールドには、クラスタ内の任意の 1 つのディスクセットが使用するメタデバイスの予想最高数を設定する必要があります。 たとえば、最初の 15 のディスクセットは 10 個のメタデバイスを使用するが、16 番目のディスクセットは 1000 個のメタデバイスを使用するという場合は、nmd は最低でも 1000 に設定する必要があります。

注意 - 注意 -

あらゆるクラスタノード (クラスタペアトポロジの場合はクラスタペア) の md.conf ファイルの内容は、それぞれのノードがサービスを提供する論理ホスト数に関係なく、同一である必要があります。このガイドラインに従っていない場合は、重大な Solstice DiskSuite エラーが発生し、データが失われることがあります。

Solstice DiskSuite ファイルシステムの配置を計画するにあたっては、次のことを考慮してください。

注 -

スライス 2 によるスライス 6 と 0 のオーバーラップ部分は、UFS ログが存在しない raw デバイスに使用されます。

どのディスクセットについても、最初の 2 つのコントローラの先頭ドライブは、表 2-3 に示すようにパーティション分割します。

各多重ホストディスクの先頭または最後の 2M バイトは、パーティション 7 として Solstice DiskSuite 用に予約されます。

表 2-2 ドライブの多重ホストディスクのパーティション分割

スライス 

説明 

7 

2M バイト (Solstice DiskSuite 用に予約) 

6 

UFS ログ 

0 

ディスクの残り領域 

2 

スライス 6 と 0 のオーバーラップ部分 

表 2-3 最初の 2 つのコントローラの先頭ドライブの多重ホストディスクのパーティション分割

スライス 

説明 

7 

2M バイト (Solstice DiskSuite 用に予約) 

5 

2M バイト (HA 管理ファイルシステム用の UFS ログ) 

4 

9M バイト (HA 管理ファイルシステム用の UFS マスター) 

6 

UFS ログ 

0 

ディスクの残り領域 

2 

スライス 6 と 0 のオーバーラップ部分 

VERITAS Volume Manager を含むファイルシステム

論理ホストのディスクグループに、UNIX File System (UFS) または VERITAS File System (VxFS) ファイルシステムを作成できます。クラスタノードで論理ホストをマスターすると、マスターする側のノードの指定マウント先に、その論理ホストのディスクグループに関連付けられているファイルシステムがマウントされます。

論理ホストを再構成すると、Sun Cluster は、その論理ホストをマウントする前に fsck コマンドを実行することによってファイルシステムを検査します。fsck コマンドは UFS ファイルシステムに対して非対話型の並列モードでファイルシステム検査を行いますが、この検査には多少時間がかかり、再構成プロセスに影響します。VxFS は、このファイルシステム検査時間データサービスを大幅に短縮し、これは、データサービスに大きなファイルシステム (500M バイト超) が使用されている場合に特に顕著です。

ミラー化ボリュームの構成では、必ずダーティリージョンログ (DRL) を追加して、システムがクラッシュした場合のボリューム回復時間の短縮を図ってください。クラスタでミラー化ボリュームを使用する場合、500M バイトを超えるボリュームには DRL を割り当てる必要があります。

VxVM では、ディスクグループを作成するときに任意のディスクグループが使用する最高ボリューム数を予想することが重要な作業になります。このボリューム数が 1000 未満の場合は、デフォルトのマイナー番号付けを利用できます。ボリューム数が 1000 以上の場合は、ディスクグループのボリュームにマイナー番号を割り当てる方法を綿密に計画する必要があります。同じノードが共有するディスクグループの間でマイナー番号を重複して割り当てないでください。

デフォルトの番号付けを利用でき、すべてのディスクグループがインポートされている場合は、ディスクグループを作成するときに vxdg init コマンドで minor オプションを使用する必要はありません。それ以外の場合は、minor オプションを使用して、ボリュームのマイナー番号が重複して割り当てられないようにする必要があります。マイナー番号は後で変更できますが、その場合には、ディスクグループの再起動と再インポートが必要になります。詳細は、vxdg(1M) のマニュアルページを参照してください。

マウント情報

/etc/vfstab ファイルには、ローカルデバイスに置かれているファイルシステムのマウント先の情報が含まれています。多重ホストファイルシステムが論理ホストに使用される場合、潜在的に論理ホストをマスターできるノードはすべてこのマウント情報を持つようにします。

論理ホストのファイルシステムに対するマウント情報は、それぞれのノード上の、/etc/opt/SUNWcluster/conf/hanfs/vfstab.logicalhost という名前の独立したファイルに保持されます。このファイルの形式は、管理しやすいよう、/etc/vfstab ファイルと同じになっています。ただし、その中のすべてのフィールドが使用されるわけではありません。

注 -

クラスタを構成するすべてのノードの間で vfstab.loghost ファイルに矛盾がないようにする必要があります。rcp コマンドまたはファイル転送プロトコル (FTP) を使用して、クラスタの他のすべてのノードにファイルをコピーしてください。あるいは、crlogin または ctelnet を使用して、ファイルのすべてを同時に編集してください。

ファイルシステムをマウントできるのは、ノードによって対応するディスクグループがインポートされている場合のみのため、複数のノードが同じファイルシステムを同時にマウントすることはできません。クラスタフレームワークの論理ホスト再構成シーケンスでは、ディスクグループのインポートと論理ホストのマスター権の整合性および一意性が適用されます。

SPARCstorage Array からの起動

Sun Cluster は、SPARCstorage Array (SSA) 内のプライベートディスクあるいは共有ディスクからの起動に対応しています。

SSA から起動ディスクを使用するにあたっては、次のことを考慮してください。

論理ホストの構成計画

ディスクグループは、1 つ以上のデータサービス用のデータを保持します。一般に、データサービスは他のデータサービスと論理ホストを共有するため、それらデータサービスのフェイルオーバーはまとめて行われます。特定の 1 つのデータサービスが他のデータサービスから独立してフェイルオーバーできるようにするには、そのデータサービスにだけ 1 つの論理ホストを割り当てて、他のデータサービスと論理ホストを共有できないようにします。

インストールおよび構成では、すべての論理ホストに対して次の項目を設定する必要があります。

付録 A 「構成ワークシートと構成例」 の論理ホストワークシートを使用して、これらの情報を記録してください。

論理ホストの構成を計画するにあたっては、次のことを考慮してください。

クラスタ構成データベース用ボリュームの計画

Sun Cluster インストールと構成では、クラスタ構成データベース (CCD) ボリュームを構成して、内部構成データを格納できます。VxVM を使用する 2 ノードのクラスタでは、CCD ボリュームをノード間で共有して、CCD の可用性の向上を図ることができます。3 ノード以上のクラスタの場合、それぞれのノードは CCD のコピーをローカルに保持します。共有 CCD の構成についての詳細は、「共有 CCD ボリュームの構成」を参照してください。

注 -

Solstice DiskSuite を使用するノード 2 つのクラスタで共有 CCD を使用することはできません。

それぞれのノードが専用の CCD のコピーを保持する場合、デフォルトでは、CCD に対する更新は、ノードの 1 つがクラスタのメンバーでなくなったときに無効になります。これにより、1 つのノードしか動作していないときにデータベースの同期が取れなくなることはなくなります。

CCD は、共有ボリューム用としてディスクグループの 2 つのディスクを必要とします。これらのディスクは CCD 専用であり、他のアプリケーションやファイルシステム、データベースが使用することはできません。

最高の可用性を得るには、CCD をミラー化してください。CCD を構成する 2 つのディスクはそれぞれ別のコントローラに存在するようにします。

VxVM を使用するクラスタの場合は、scinstall(1M) スクリプトから、構成内の共有ボリューム上に CCD を構成する方法について問い合わせがあります。

CCD の概要については、第 1 章「Sun Cluster 環境について」を参照してください。CCD を管理する手順については、『Sun Cluster 2.2 のシステム管理』の全般的な Cluster の管理の説明を参照してください。

注 -

インストールでは、同じコントローラ上のディスクを選択できます。しかし、同じコントローラ上のディスクを選択すると、単一点障害が起きる可能性があるため、選択しないでください。

定足数デバイスの計画 (VxVM)

ボリュームマネージャとして VERITAS Volume Manager を使用する場合は (またはクラスタ機能がない)、クラスタノード数に関係なく定足数デバイスを設定する必要があります。Sun Cluster のインストールでは、scinstall(1M) から、定足数デバイスを設定するように促されます。

定足数デバイスは、アレイコントローラまたはディスクのいずれかです。

クラスタソフトウェアのインストールでは、次の事項を決定する必要があります。

クラスタのトポロジに関する注意事項

クラスタ用の定足数デバイスを選択する前に、その選択が意味することに注意してください。クラスタのどのノードペアも、必ず定足数デバイスを 1 つ持つ必要があります。つまり、多重ホストディスクを共有するノードセットごとに定足数デバイスを 1 つ割り当てる必要があります。クラスタ内のすべてノードに、そこに接続されている定足数デバイスだけではなく、クラスタ内のすべての定足数デバイスの情報を通知する必要があります。クラスタのインストール時に scinstall(1M) コマンドでは、ペアを組むことができるノードペアを次々と提供し、定足数デバイスの候補となる一般的なデバイスを表示します。

デュアルポート式のディスクを持つ、2 ノードのクラスタでは、単一の定足数デバイスを指定する必要があります。

デュアルポート式のディスクを持つ、3 ノード以上のクラスタでは、必ずしもクラスタノードのすべてがディスクサブシステム全体にアクセスするわけではありません。そうした構成では、ディスクを共有するノードセットごとに定足数デバイスを 1 つ指定する必要があります。

Sun Cluster 構成では、クラスタを構成する全ノードに Sun StorEdge A5000 などのディスク記憶装置を接続できます。この構成により、OPS などのアプリケーションは 3 つ以上のノードからなるクラスタ上で動作することができます。このように、クラスタの全ノードに物理的に接続されたディスク記憶装置は直接接続デバイスと呼びます。この種のクラスタでは、直接接続デバイスから 1 つの定足数デバイスを選択する必要があります。

直接接続デバイスを持つクラスタでは、クラスタインターコネクトで問題が発生すると、次のいずれか 1 つのことが発生します。

全ノードに対する直接接続デバイスを持たないクラスタの場合、定義では、複数の定足数デバイス (ディスクを共有するノードペアごとに 1 つ) が存在することになります。この構成では、2 つのノードが残って、その 2 つのノードが同じ定足数デバイスを共有する場合にのみ、定足数デバイスがその役割を果たします。

ノードに障害が発生した場合は、定足数デバイスを予約することができるノードが、クラスタの唯一のノードとして残ります。共有ディスク上のデータの完全性を維持するには、このようなノードが必要です。

データ移行方針の作成

Sun Cluster 環境に既存のデータを移行する方法を作成するにあたっては、次のことを考慮してください。

多重ホストバックアップ戦略の選択

Sun Cluster 構成の多重ホストディスクにデータを読み込む前に、データバックアップ計画を立ててください。Solstice BackupTM 、ufsdump または VERITAS NetBackup を使用して、Sun Cluster 構成をバックアップすることを推奨します。

Online:BackupTM と Solstice Backup の間に互換性はないため、バックアップ方法を Online:Backup から Solstice Backup に変更する場合は、特別な注意が必要です。システム管理者が第 1 に決定すべきことは、Solstice Backup を使用するようになった後で、Online:Backup でバックアップしたファイルをオンラインで利用できるようにするかどうかということです。バックアップ方法の変更についての詳細は、Solstice Backup のマニュアルを参照してください。

VERITAS NetBackup は、強力でスケーラブルなバックアップソリューションです。NetBackup マスターサーバーを Sun Cluster HA for NetBackup の制御のもとに置けば、高度な可用性をもつサーバーになります。VERITAS NetBackup の詳細は、第 15 章「並列データベースシステムのインストールと構成」を参照してください。

問題解決の計画

システムの構成を完了して、動作し始めたら、次のファイルを保存してください。クラスタで問題が発生した場合に、クラスタの問題をデバッグし、解決するのに役立つことがあります。