この章では、Sun Cluster の構成の計画と、その手順について説明します。
管理ワークステーション
クラスタの固有名と命名規則
ネットワーク接続
ボリューム管理
Solaris オペレーティング環境
多重ホストディスクの要件
多重ホストディスク上のファイルシステムの配置
論理ホストの構成 (HA 構成のみ)
クラスタ構成データベース (CCD)
定足数デバイス (SSVM および CVM のみ)
データ移行の方針
多重ホストバックアップの方針
構成の計画を立てる前に、「信頼性向上のための構成規則」で説明している信頼性に関する問題点を考慮してください。また、Sun Cluster 環境には、構成の計画を完了する前に考慮すべき構成上の制限事項があります。この制限事項ついては、「構成上の制限事項」で説明します。
付録 A 「構成ワークシートと構成例」 には、構成計画に役立つワークシートが用意されています。
この節では、構成の計画に関係する作業と問題点について説明します。これらの作業を示されている順序通りに行う必要はありませんが、構成計画の一環としてすべての説明を参照してください。
アクティブクラスタを管理するための専用の SPARCTM ワークステーション (「管理ワークステーション」と呼ぶ) を使用するかどうかを決定する必要があります。管理ワークステーションは、クラスタのノードではありません。管理ワークステーションは、端末集配信装置に対する telnet セッションを実行して、コンソールのログインを容易に行える SPARC マシンであれば何でもかまいません。また、Sun Enterprise 10000 プラットフォームでは、管理ワークステーションから netcon コマンドを使用してシステムサービスプロセッサ (SSP) にログインし、接続する必要があります。
Sun Cluster は専用の管理ワークステーションを必要としませんが、専用の管理ワークステーションを使用することには、次の利点があります。
1 台のマシンにコンソールと管理ツールをまとめられることにより、中央からのクラスタ管理が可能になります。
エンタープライズサービスによる短時間の問題の解決が可能になります。
管理ワークステーションでは、クラスタの他のノードと同じバージョンの Solaris オペレーティング環境 (Solaris 2.6 または Solaris 7) を実行する必要があります。
1 つのクラスタノードを管理ワークステーションとクラスタノードの両方の目的に使用できます。このためには、クラスタノードを「クライアント」と「サーバー」の両方としてインストールする必要があります。
クラスタを構成する前に、次の項目の名前を決定する必要があります。
クラスタそのもの
物理ホスト
論理ホスト
ディスクグループ
ネットワークインタフェース
ネットワークインタフェース名 (および関連付けられた IP アドレス) は、各パブリックネットワーク上のすべての論理ホストに必要です。一定の命名規則を使用する必要はありませんが、このマニュアルでは、推奨する命名規則として次の命名規則を使用します。付録 A 「構成ワークシートと構成例」 の構成ワークシートを利用してください。
クラスタ - 構成作業の一貫として、クラスタ名の指定が求められます。任意の名前を選択できます。Sun Cluster には、クラスタ名に関する制限はありません。
物理ホスト - 物理ホスト名は、論理ホスト名に接頭辞 phys- を付けることによって作成します (物理ホストはそれぞれ論理ホストを 1 つだけマスターします)。たとえば、hahost1 という名前の論理ホストをマスターする物理ホストの名前は、phys-hahost1 とします。Sun Cluster には、複数の論理ホストをマスターする物理ホストに対する命名規則あるいはデフォルト名はありません。
ネームサービスとして DNS を使用する場合は、物理ホスト名や論理ホスト名に下線 (_) を使用しないでください。DNS は、下線を含むホスト名を認識しません。
論理ホストとディスクグループ - Sun Cluster では、論理ホストとディスクグループに異なる名前を付けることができます。しかし、同じ名前を使用することは、Sun Cluster の慣習であり、管理が容易になります。詳細は、「論理ホストの構成計画」を参照してください。
パブリックネットワーク - パブリックネットワーク上で物理ホストの識別に使用される名前は、主物理ホスト名です。二次パブリックネットワーク上で物理ホストの識別に使用される名前は、二次物理ホスト名です。図 2-1 で示すように、物理ホストには、次の規則に基づいて名前を付けてください。
主物理ホスト名には、上記の説明のように単に物理ホスト名を使用します。たとえば、論理ホスト hahost1 に関連付けられている物理ホストには、phys-hahost1 という名前を使用します。
二次物理ホスト名では、物理ホスト名に、二次ネットワークアドレスであることを示す接尾辞を付けます。たとえば、物理ホスト phys-hahost1 がネットワークアドレス 192.9.201 の二次ネットワークに接続されている場合は、二次物理ホスト名として phys-hahost1-201 という名前を付けます。
主物理ホスト名は、uname -n によって返されるノード名です。
プライベートインターコネクト - プライベートインターコネクトに対するデフォルトの命名規則はありません。
図 2-1 に命名規則の例を示します。
ローカルエリアネットワークに少なくとも 1 つのパブリックネットワークを接続し、クラスタのノード同士を 2 つのプライベートインターコネクトで接続する必要があります。Sun Cluster ネットワーク構成の概要については第 1 章「Sun Cluster 環境について」、ネットワーク計画ワークシートについては付録 A 「構成ワークシートと構成例」 をそれぞれ参照してください。
パブリックネットワーク構成を計画するにあたっては、次のことを考慮してください。
少なくとも 1 つのパブリックネットワークをすべてのクラスタノードに接続する必要があります。ハードウェア構成が許す限り、パブリックネットワークはいくつでも追加接続できます。
HA データサービスを提供する構成では、各パブリックネットワーク上のすべての論理ホストに IP アドレスとネットワークインタフェース名を割り当てる必要があります。これにより多数のホスト名が作成される可能性があります。詳細は、「名前と命名規則の設定」を参照してください。クラスタノードの各 /etc/hosts ファイルに論理ホスト名をすべて追加する必要があります。
Sun Cluster には、パブリックネットワークインタフェースが、指定したバックアップグループ内の別のインタフェースにフェイルオーバーすることを可能にするパブリックネットワーク管理 (PNM) コンポーネントが含まれています。PNM についての詳細は、『Sun Cluster 2.2 のシステム管理』を参照してください。
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 にパスワードを割り当てる必要があります。
Sun Cluster ソフトウェアをインストールするには、同じバージョンの Solaris オペレーティング環境 (Solaris 2.6 または Solaris 7) を使用して、クラスタ内のすべてのノードをインストールする必要があります。クラスタノードに Solaris をインストールするときは、この節で説明する一般的な規則に従ってください。
すべての Sun Cluster ノードに全体ディストリビューション Solaris ソフトウェアパッケージをインストールします。
Sun Enterprise 10000 以外のプラットフォームには、Solaris オペレーティング環境のソフトウェアパッケージとして、少なくとも全体ディストリビューションをインストールする必要があります。Sun Enterprise 10000 システムには、全体ディストリビューションプラス OEM が必要です。
Solaris オペレーティング環境のインストールを完了したら、最新のパッチをインストールする必要があります。Solaris 2.6 または Solaris 7 オペレーティング環境用の必須パッチの最新リストについては、ご購入先にお問い合わせください。
以前のバージョンの Solaris オペレーティング環境からアップグレードする場合は、次の規則に従ってください。
オペレーティング環境を再インストールするのではなく、Solaris 対話式インストールプログラムのアップグレードオプションを使用する必要があります。また、ルート (/) と /usr スライスのサイズを大きくして、Solaris 環境を収容する準備をしておく必要があります。
Solaris 対話式インストールプログラムのアップグレードオプションには、現在のファイルシステムにアップグレード用の十分な空間がない場合に、ディスク空間を割り当てる機能が用意されています。デフォルトでは、自動配置機能によって、アップグレードが成功するようにディスク空間を再割り当てする方法が試されます。自動配置機能がディスク空間の再割り当て方法を決定できない場合は、移動または変更できるファイルシステムを手動で指定して、再度自動配置機能を実行する必要があります。
はじめて Sun Cluster をインストールする場合は、次の規則に従ってください。
すべての Sun Cluster ノードをスタンドアロンとして構成してください。この構成は、Solaris インストールプログラムから質問に応答することによって行います。
エクスポート済みファイルシステムを定義しないでください。HA-NFS ファイルシステムは、/export にはマウントされません。HA-NFS ファイルシステムのみ、Sun Cluster ノード上で NFS により共有します。
Solaris の電源管理の自動停止機能は無効にしてください (Sun Cluster 構成内のノードに該当する場合)。詳細は、pwconfig(1M) および power.conf(4) のマニュアルページを参照してください。
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 (有効) が返された場合は、次のコマンドを実行することによってインタフェースグループを無効にしてください。
set ip:ip_enable_group_ifs=0 |
/etc/system ファイルを編集した場合は、必ずシステムを再起動してください。
Solaris 2.6 または Solaris 7 をインストールすると、システムディスクは、ルート (/) や /usr、その他標準のファイルシステム用のスライスにパーティション分割されます。Sun Cluster および使用するボリュームマネージャに求められる条件を満たすには、このパーティション構成を変更する必要があります。この後の説明に従って、ディスク空間を割り当ててください。
表 2-1 に、スライス番号、内容、およびファイルシステム、スワップ空間、スライスに推奨する空間割り当て量を示します。JumpStartTM を使用して Solaris をインストールすると、デフォルトでこれらの値が使用されますが、Sun Cluster で、この構成が必須というわけではありません。
表 2-1 ファイルシステム用スライス
番号 |
内容 |
割り当て量 (M バイト) |
---|---|---|
0 |
ルート (/) |
80 |
1 |
スワップ |
50 |
3 |
/var |
残りの空き領域 (他の割り当て量によって変化) |
5 |
/opt |
300 |
6 |
/usr |
300 |
Solstice DiskSuite を使用する場合は、上記とは別に、メタデバイス状態データベースの複製用としてシステムディスクに 10M バイトを確保する必要があります。複製についての詳細は、Solstice DiskSuite のマニュアルを参照してください。
SSVM または CVM を使用する場合は、上記とは別に、2 つのパーティションと、SSVM または CVM が管理する各多重ホストディスク上に、rootdg ディスクグループ用として少量の空き領域 (1024 セクター分) を確保する必要があります。この空き領域は各ディスクの先頭または最後の部分に確保します。各ディスクの先頭または最後の部分は、スライスに割り当てないでください。詳細は、「Sun StorEdge Volume Manager と Cluster Volume Manager に関する注意事項」を参照してください。
ローカルディスクのルート (/) スライスには、各種ファイルおよびディレクトリ用の領域のほかに、/devices のデバイス i ノードと /dev のシンボリックリンク用の領域も存在する必要があります。
また、ルートスライスには、以下を格納できる十分な大きさである必要があります。
Solaris システムソフトウェア
Sun Cluster、使用するボリューム管理ソフトウェアの一部コンポーネント、サン以外のソフトウェアパッケージ
ディスク装置およびボリュームマネージャに対する /dev 内シンボリックリンク用データ空間
Sun Cluster は、root プロセスを実行するさまざまなシェルスクリプトを使用します。このため、root ユーザー用の /.cshrc* および /.profile ファイルは空にしておくか、クラスタノードに存在しないようにします。
大量のディスクドライブで構成される場合は、大きなルートファイルシステムが必要になることがあります。
空き領域が不足した場合は、すべてのクラスタノードにオペレーティング環境を再インストールして、ルートスライス内の空き領域を追加する必要があります。ルートスライスの全空間の少なくとも 20% を空き領域として確保してください。
/usr スライスは、ユーザーファイルシステムを保持します。/var スライスは、システムログファイルを保持します。/opt スライスは、Sun Cluster とデータサービスソフトウェアパッケージを保持します。Solaris をインストールするときの割り当て値の変更についての詳細は、『Solaris のインストール (上級編)』を参照してください。
Sun Cluster は、ボリューム管理ソフトウェアを使用して、ディスクをディスクグループにまとめ、1 つの単位で管理できるようにします。Sun Cluster は、Solstice DiskSuite、Sun StorEdge Volume Manager (SSVM)、Cluster Volume Manager (CVM) をサポートしています。ボリュームマネージャは、1 つのクラスタ構成内で 1 つだけ使用できます。
ボリューム管理ソフトウェアは、Solaris オペレーティング環境をインストールした後にインストールする必要があります。ただし Sun Cluster ソフトウェアの前または後のどちらにインストールしてもかまいません。ボリューム管理ソフトウェアのインストール方法については、使用するボリューム管理ソフトウェアのマニュアルと、このマニュアルの第 3 章「Sun Cluster ソフトウェアのインストールと構成」を参照してください。
ディスクを構成するにあたっては次のガイドラインに従ってください。
必須ではありませんが、ルートディスクのミラー化を推奨します。
多重ホストディスクはすべて複数のディスクアレイにまたがってミラー化する必要があります。これに対する唯一の例外は、Sun StorEdge A3000 です。Sun StorEdge A3000 は、ミラー化するかハードウェアを RAID5 の構成にします。
必須ではありませんが、ホットスペアの利用を強く推奨します。
ボリューム管理に関係する推奨ディスク配置については、「ボリュームマネージャ用スライス」を参照してください。また、その他の制限事項については、使用するボリュームマネージャのマニュアルを参照してください。
Solstice DiskSuite の構成を計画するにあたっては、次のことを考慮してください。
ディスクセット内のファイルシステムには、必ずトランスメタデバイスを使用してください。
2 つのディスク拡張装置だけで Solstice DiskSuite を実行する場合は、Solstice DiskSuite メディエータを使用する必要があります。
構成内のディスクセットに対して Solstice DiskSuite メディエータを使用する場合は、2 つのクラスタノードだけがメディエータホストの役割を果たすことができます。これら 2 つのノードは、どちらのノードがディスクセットをマスターするかに関係なく、メディエータを必要とするすべてのディスクセットに使用する必要があります。このため、3 ノード以上の Sun Cluster 構成では、実際にはディスクセットの潜在的マスターではないホストがディスクセットのメディエータホストになる可能性があります。
SSVM あるいは CVM の構成を計画するにあたっては、次のことを考慮してください。
クラスタノードそれぞれにデフォルトのディスクグループ (rootdg) を作成する必要があります。この rootdg グループは、スライス 1 つ (単一のディスク) またはディスク全体で構成します。rootdg グループはカプセル化することができます。
rootdg を単一のディスクで構成する場合は、ルートディスク上の 1 つのスライステーブルエントリと少なくとも 2 つのシリンダを空けておく要があります。
rootdg をカプセル化する場合は、2 つのディスクスライステーブルエントリを空けておく必要があります。また、カプセル化したルートディスクには、ルート (/)、/usr、/var、swap ファイルシステムのみ存在するようにします。
カプセル化すると、ボリューム管理ソフトウェアのアップグレードが難しくなります。しかし、ルートディスクをミラー化する場合は、rootdg をカプセル化する必要があります。
ディスク空間とスライスが不足していると、後で起動ディスクのカプセル化が行えなくなります。また、オペレーティング環境の再インストールが必要になることがあるため、インストール時間が長くなることがあります。
SPARCstorage Array や Sun StorEdge A5000 以外の記憶装置に Sun StorEdge Volume Manager を使用する場合は、Sun StorEdge Volume Manager 用のライセンスが必要です。SPARCstorage Array と Sun StorEdge A5000 には、SSVM 用のライセンスが含まれています。必要な SSVM ライセンスについては、Sun License Center にお問い合わせください。詳細は、http://www.sun.com/licensing/ を参照してください。
Sun Cluster で Solstice DiskSuite または Cluster Volume Manager を使用する場合、ライセンスは必要ありません。
高可用性システムの重要な特長の 1 つとして、ノードに障害が発生しても、すぐにファイルシステムをオンラインに戻せることが挙げられます。これは、ロギングファイルシステムを利用することによって行います。Sun Cluster は、Veritas の VxFS ロギングと DiskSuite の UFS ロギング、Solaris の UFS ロギングの 3 つのロギングファイルシステムをサポートしています。Oracle Parallel Server (OPS) と組み合わせた場合、Cluster Volume Manager (CVM) は raw パーティションを使用するため、ロギングファイルシステムを使用しません。しかし、クラスタ内では、OPS と HA データサービスと一緒に CVM を実行することができます。この構成では、OPS 共有ディスクグループは raw パーティションを使用しますが、HA ディスクグループが VxFS または Solaris UFS ロギングファイルシステム (Solaris UFS ロギングは Solaris 7 でのみサポート) のいずれかを使用できます。上記の共存型の CVM 構成を除けば、Sun Cluster は、次の表に示すボリュームマネージャとロギングファイルシステムの組み合わせをサポートします。
表 2-2 サポートされるファイルシステムとボリュームマネージャの組み合わせ
Solaris オペレーティング環境 |
ボリュームマネージャ |
サポートされるファイルシステム |
---|---|---|
Solaris 2.6 |
Sun StorEdge Volume Manager |
VxFS、UFS (ロギングなし) |
Solstice DiskSuite |
DiskSuite UFS ロギング |
|
Solaris 7 |
Solstice DiskSuite |
DiskSuite UFS ロギング、Solaris UFS ロギング |
CVM は、ロギングファイルシステムが提供する機能に似た、ダーティリージョンログ (DRL) という機能を使用して、再起動後の高速回復の支援をします。CVM については、Sun Cluster に付属している『Sun Cluster 2.2 Cluster 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 に移動するデータ量を求めるときは、個々のディスク拡張装置について、利用できるディスクのサイズを考慮してください。
Sun StorEdge A3000 の場合は、装置 1 つに 2 つのコントローラがあるため、必要なディスク拡張装置は 1 つだけです。Sun StorEdge MultiPack の場合は、少なくとも 2 つのディスク拡張装置が必要になります。
環境によっては、複数の小さなファイルシステムをマージして、1 つの大きなファイルシステムにした方が有益であることがあります。1 つのファイルシステムにすることによって管理するファイルシステム数が減り、クラスタのテイクオーバーの高速化に役立つことがあります。
Solstice DiskSuite の構成で 2 つのディスク拡張装置しかない場合は、dual-string メディエータの構成にする必要があります。ディスク拡張装置が 3 つ以上ある場合、メディエータの構成をする必要はありません。Sun StorEdge Volume Manager と Cluster Volume Manager は、メディエータをサポートしていません。dual-string メディエータ機能についての詳細は、『Sun Cluster 2.2 のシステム管理』の dual-string メディエータに関する説明を参照してください。
サポートされるディスクタイプについては、『Sun Cluster 2.2 ご使用にあたって』を参照してください。
ディスク空間の拡張を計画するときは、次のことを考慮してください。
初期構成で多重ホストディスク拡張装置に空のスロットを残しておくことにより、後で簡単にディスクを追加できます。
ディスク拡張装置を後で追加する場合、データを再構成して、1 つのディスク拡張装置内でミラー化が行われないようにしなければならないことがあります。既存のすべてのディスク拡張装置が一杯になったときに、データを再構成しないでディスク拡張装置を追加する最も簡単な方法は、ディスクをペアで追加する方法です。
多重ホストディスク拡張装置では、異なるサイズのディスクを使用できます。どのサイズのドライブを使用するか決定するときは、次のことを考慮してください。
小容量のドライブを使用すると、スピンドル数が多くなることがあります。この場合、ディスクの入出力レートが同じであるとすると、潜在的な入出力帯域幅が大きくなります。
大容量のドライブを使用すると、構成に必要とされるデバイス数が少なくなります。テイクオーバー時間の一部はテイクオーバーされるドライブ数に依存するため、テイクオーバーの高速化に役立つことがあります。
必要なディスク数は、ディスク拡張装置のディスクサイズで、選択した総ディスク容量 (ミラーを含む) を除算することによって求めることができます。
Sun Cluster は、特定のディスク配置あるいはファイルシステムサイズを必要としません。ファイルシステム階層に求められる条件は、使用するボリューム管理ソフトウェアに依存します。
Sun Cluster は、ボリューム管理ソフトウェアに関係なく、1 つのディスクグループに、HA 管理ファイルシステムの役割を果たすファイルシステムを少なくとも 1 つ必要とします。 一般に、この管理ファイルシステムは、/logicalhost (logicalhost は、実際に使用している論理ホスト名) にマウントされ、最低でも 10M バイトの大きさである必要があります。管理ファイルシステムは、データサービスの構成情報を含むプライベートディレクトリの格納に使用されます。
Solstice DiskSuite を使用するクラスタの場合は、HA 管理ファイルシステムを含むメタデバイスを作成する必要があります。HA 管理ファイルシステムは、他の多重ホストファイルシステムと同じ構成にしてください。つまり、ミラー化して、トランスデバイスとして構成してください。
SSVM または CVM を使用するクラスタの場合は、Sun Cluster によって、dg-stat (dg は、ボリュームが作成されるディスクグループ名) というボリュームに HA 管理ファイルシステムが作成されます。通常、dg は、論理ホストを定義するときに指定するディスクグループリストの先頭のディスクグループ名です。
ファイルシステムサイズとディスク配置を計画するときは、次のことを考慮してください。
ミラー化するときは、複数のコントローラにまたがってミラー化されるようにディスクを配置してください。
類似ディスクのパーティション分割方法を統一すると、管理作業が簡単になります。
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-3 に示すパーティション分割方式を使用してください。
スライス |
説明 |
---|---|
7 |
2M バイト (Solstice DiskSuite 用に予約) |
6 |
UFS ログ |
0 |
ディスクの残り領域 |
2 |
スライス 6 と 0 のオーバーラップ部分 |
一般に、UFS ログを作成した場合は、スライス 6 のデフォルトのサイズは、システム上の最大多重ホストディスクサイズの 1% です。
スライス 2 によるスライス 6 と 0 のオーバーラップ部分は、UFS ログが存在しない raw デバイスに使用されます。
どのディスクセットについても、最初の 2 つのコントローラの先頭ドライブは、表 2-4 に示すようにパーティション分割します。
表 2-4 最初の 2 つのコントローラの先頭ドライブの多重ホストディスクのパーティション分割
スライス |
説明 |
---|---|
7 |
2M バイト (Solstice DiskSuite 用に予約) |
5 |
2M バイト (HA 管理ファイルシステム用の UFS ログ) |
4 |
9M バイト (HA 管理ファイルシステム用の UFS マスター) |
6 |
UFS ログ |
0 |
ディスクの残り領域 |
2 |
スライス 6 と 0 のオーバーラップ部分 |
ディスクグループには、必ず HA 管理ファイルシステムが関連付けられます。この HA 管理ファイルシステムが NFS で共有されることはありません。HA 管理ファイルシステムは、データサービスに固有の状態あるいは構成情報用に使用されます。
各多重ホストディスクの先頭または最後の 2M バイトは、パーティション 7 として Solstice DiskSuite 用に予約されます。
論理ホストのディスクグループに、UNIX File System (UFS) または Veritas File System (VxFS) ファイルシステムを作成できます。クラスタノードで論理ホストをマスターすると、マスターする側のノードの指定マウント先に、その論理ホストのディスクグループに関連付けられているファイルシステムがマウントされます。
論理ホストを再構成すると、Sun Cluster は、その論理ホストをマウントする前に fsck コマンドを実行することによってファイルシステムを検査します。fsck コマンドは UFS ファイルシステムに対して非対話型の並列モードでファイルシステム検査を行いますが、この検査には多少時間がかかり、再構成プロセスに影響します。VxFS は、このファイルシステム検査時間データサービスを大幅に短縮し、これは、データサービスに大きなファイルシステム (500M バイト超) が使用されている場合に特に顕著です。
ミラー化ボリュームの構成では、必ずダーティリージョンログ (DRL) を追加して、システムがクラッシュした場合のボリューム回復時間の短縮を図ってください。クラスタでミラー化ボリュームを使用する場合、500M バイトを超えるボリュームには DRL を割り当てる必要があります。
SSVM や CVM では、ディスクグループを作成するときに任意のディスクグループが使用する最高ボリューム数を予想することが重要な作業になります。このボリューム数が 1000 未満の場合は、デフォルトのマイナー番号付けを利用できます。ボリューム数が 1000 以上の場合は、ディスクグループのボリュームにマイナー番号を割り当てる方法を綿密に計画する必要があります。同じノードが共有するディスクグループの間でマイナー番号を重複して割り当てないでください。
デフォルトの番号付けを利用でき、すべてのディスクグループがインポートされている場合は、ディスクグループを作成するときに vxdg init コマンドで minor オプションを使用する必要はありません。それ以外の場合は、minor オプションを使用して、ボリュームのマイナー番号が重複して割り当てられないようにする必要があります。マイナー番号は後で変更できますが、その場合には、ディスクグループの再起動と再インポートが必要になります。詳細は、vxdg(1M) のマニュアルページを参照してください。
/etc/vfstab ファイルには、ローカルデバイスに置かれているファイルシステムのマウント先の情報が含まれています。多重ホストファイルシステムが論理ホストに使用される場合、潜在的に論理ホストをマスターできるノードはすべてこのマウント情報を持つようにします。
論理ホストのファイルシステムに対するマウント情報は、それぞれのノード上の、/etc/opt/SUNWcluster/conf/hanfs/vfstab.logicalhost という名前の独立したファイルに保持されます。このファイルの形式は、管理しやすいよう、/etc/vfstab ファイルと同じになっています。ただし、その中のすべてのフィールドが使用されるわけではありません。
クラスタを構成するすべてのノードの間で vfstab.loghostname ファイルに矛盾がないようにする必要があります。rcp コマンドまたはファイル転送プロトコル (FTP) を使用して、クラスタの他のすべてのノードにファイルをコピーしてください。あるいは、crlogin または ctelnet を使用して、ファイルを同時に編集してください。
ファイルシステムをマウントできるのは、ノードによって対応するディスクグループがインポートされている場合のみのため、複数のノードが同じファイルシステムを同時にマウントすることはできません。クラスタフレームワークの論理ホスト再構成シーケンスでは、ディスクグループのインポートと論理ホストのマスター権の整合性および一意性が適用されます。
Sun Cluster は、SPARCstorage Array (SSA) 内のプライベートディスクあるいは共有ディスクからの起動に対応しています。
SSA から起動ディスクを使用するにあたっては、次のことを考慮してください。
クラスタノードの起動ディスクはそれぞれに異なる SSA に存在する必要があります。ノードの起動ディスクが同じ SSA に存在していると、1 つのコントローラが失われた場合に、すべてのノードが停止します。
SSVM あるいは CVM 構成の場合は、同じトレイに起動ディスクと定足数デバイスを設定しないでください。2 ノードのクラスタの場合は、特にこのことが当てはまります。同じトレイに両方を配置すると、トレイを取り外したときに、クラスタから定足数デバイスばかりでなく、ノードの 1 つも失われます。どのような理由であれ、この間に残りのノードで再構成が行われると、クラスタそのものが失われます。起動ディスクと定足数デバイスを含むコントローラが故障した場合、必然的に、定足数デバイスを利用することはできなくなるため、その不良コントローラが存在するノードは停止するかクラッシュし、もう一方のノードは再構成されて異常終了します (これは、起動ディスクがあり、ルートディスクのミラー化が行われていない SSA 2 つの最小構成で発生する可能性があります)。
起動可能な SSA 構成では、起動ディスクをミラー化することを推奨します。ただし、この構成にすると、ソフトウェアのアップグレードが影響を受けます。起動ディスクがミラー化されている間は、Solaris とボリューム管理ソフトウェアのどちらもアップグレードすることはできません。こうした構成では、ルートファイルシステムが壊れないよう注意しながら、アップグレードを行う必要があります。ルートファイルシステムのミラー化についての詳細は、「ルート (/) のミラー化」を参照してください。
ディスクグループは、1 つ以上のデータサービス用のデータを保持します。一般に、データサービスは他のデータサービスと論理ホストを共有するため、それらデータサービスのフェイルオーバーはまとめて行われます。特定の 1 つのデータサービスが他のデータサービスから独立してフェイルオーバーできるようにするには、そのデータサービスにだけ 1 つの論理ホストを割り当てて、他のデータサービスと論理ホストを共有できないようにします。
インストールおよび構成では、すべての論理ホストに対して次の項目を設定する必要があります。
デフォルトマスター - どの論理ホストも、それが接続される任意の物理ホストによって潜在的にマスターされることができます。
HA 管理ファイルシステム - 管理ファイルシステムに対する論理ホスト上のマウント先です。詳細は、「多重ホストディスク上のファイルシステム配置計画」を参照してください。
vfstab ファイル名 - 論理ホストは、それぞれに vfstab ファイルを使用して、ファイルシステム情報を格納する必要があります。一般に、このファイル名は vfstab.logicalhost です。
ディスクグループ - ディスクグループにはそれぞれ専用の名前を付けます。取り決めでは、ディスクグループ名と論理ホスト名は同じですが、ディスクグループに別の名前を付けることもできます。
付録 A 「構成ワークシートと構成例」 の論理ホストワークシートを使用して、これらの情報を記録してください。
論理ホストの構成を計画するにあたっては、次のことを考慮してください。
データサービスによって CPU やメモリーに多大の負荷がかからない場合は、単独でスイッチオーバーをしても、負荷均衡の利点は得られません。
N+1 構成の負荷均衡には注意してください。データサービスによって CPU あるいはメモリーに多大の負荷がかかる場合は、ホットスタンバイノードにかかる作業負荷を制限するようにします。ホットスタンバイノードに大きな負荷がかかると、アクティブノードで問題が発生した場合のテイクオーバー能力に影響が出ます。
データサービスソフトウェアが比較的安定していて、高速に起動する場合は、単独でフェイルオーバーしても、可用性の点で大きな利点は得られません。
ディスクグループ 1 つにつき少なくとも 1 つのミラー化ペアドライブが必要なため、わずかなディスク空間しか利用しないデータサービスを独立した論理ホストに配置すると、大量のディスク空間の浪費になります。
論理ホスト数が多くなるに従って、管理作業の負担が増えます。
インストールと構成では、クラスタ構成データベース (CCD) ボリュームを構成して、内部構成データを格納できます。SSVM または CVM を使用する 2 ノードのクラスタでは、CCD ボリュームをノード間で共有して、CCD の可用性の向上を図ることができます。3 ノード以上のクラスタの場合、それぞれのノードは CCD のコピーをローカルに保持します。共有 CCD の構成についての詳細は、「共有 CCD ボリュームの構成」を参照してください。
Solstice DiskSuite を使用するノード 2 つのクラスタで共有 CCD を使用することはできません。
それぞれのノードが専用の CCD のコピーを保持する場合、デフォルトでは、CCD に対する更新は、ノードの 1 つがクラスタのメンバーでなくなったときに無効になります。これにより、1 つのノードしか動作していないときにデータベースの同期が取れなくなることはなくなります。
CCD は、共有ボリューム用としてディスクグループの 2 つのディスクを必要とします。これらのディスクは CCD 専用であり、他のアプリケーションやファイルシステム、データベースが使用することはできません。
最高の可用性を得るには、CCD をミラー化してください。CCD を構成する 2 つのディスクはそれぞれ別のコントローラに存在するようにします。
CVM または SSVM を使用するクラスタの場合は、scinstall(1M) スクリプトから、構成内の共有ボリューム上に CCD を構成する方法について問い合わせがあります。
CCD の概要については、第 1 章「Sun Cluster 環境について」を参照してください。CCD を管理する手順については、『Sun Cluster 2.2 のシステム管理』の全般的な Sun Cluster の管理の説明を参照してください。
インストールでは、同じコントローラ上のディスクを選択できます。しかし、同じコントローラ上のディスクを選択すると、単一点障害が起きる可能性があるため、選択しないでください。
ボリュームマネージャとして Cluster Volume Manager または Sun StorEdge Volume Manager を使用する場合は、クラスタノード数に関係なく定足数デバイスを設定する必要があります。Sun Cluster のインストールでは、scinstall(1M) から、定足数デバイスを設定するように促されます。
定足数デバイスは、アレイコントローラまたはディスクのいずれかです。
定足数デバイスがアレイコントローラの場合は、アレイ内の全ディスクをクラスタアプリケーションに含める必要があります。アレイコントローラにプライベートデータ (プライベートファイルシステムまたはノード専用のディスクグループ) を格納することはできません。
定足数デバイスがディスクの場合は、そのディスクをクラスタアプリケーションに含める必要があります。ディスクの特定のノード専用にすることはできません。
クラスタソフトウェアのインストールでは、次の事項を決定する必要があります。
定足数構成の種別 (単純モードか複合モード) - 単純モードでは、定足数デバイスは自動的に設定されます。複合モードでは、定足数デバイスを手動で設定する必要があります。
定足数デバイスの動作 - クラスタをサブセットに分割した場合は、動作を継続するサブセットをクラスタメンバーシップモニターが自動的に選択するようにするか、アクションの指定を求めるプロンプトをシステムに出させるようにするか選択できます。
定足数デバイスのポリシー - 動作を継続するサブセットを自動的に選択させるオプションを選択した場合は、ポリシーを設定する必要があります。最小あるいは最大ノード ID を選択することによって、定足数デバイスがアクティブになったときに自動的に新しいクラスタになるノードのサブセットを指定します。定足数デバイスのポリシーについての詳細は、「定足数、定足数デバイス、障害防護」を参照してください。
デバイスの種類 - 定足数デバイスとして、多重ホストディスク拡張装置内のコントローラまたはディスクを設定できます。
ディスク拡張装置内の全ディスクを共有ディスクグループ (OPS 用) または HA ディスクグループ用に使用する場合は、アレイコントローラを定足数デバイスとして使用できます。
アレイ内の 1 つ以上のディスクをノードのプライベート記憶装置 (ファイルシステムまたは raw デバイス用) として使用する場合は、共有ディスクグループ (OPS 用) に属するか、HA ディスクグループの 1 つに属するディスクの 1 つを定足数デバイスとして使用する必要があります。
専用のディスク (データが格納されていないディスク) を定足数デバイスとして設定することもできます。
クラスタ用の定足数デバイスを選択する前に、その選択が意味することに注意してください。クラスタのどのノードペアも、必ず定足数デバイスを 1 つ持つ必要があります。つまり、多重ホストディスクを共有するノードセットごとに定足数デバイスを 1 つ割り当てる必要があります。クラスタ内のすべてノードに、そこに接続されている定足数デバイスだけではなく、クラスタ内のすべての定足数デバイスの情報を通知する必要があります。scinstall(1M) スクリプトでは、ペアを組むことができるノードペアを次々と提供し、定足数デバイスの候補となる一般的なデバイスを表示します。
デュアルポート式のディスクを持つ、2 ノードのクラスタでは、単一の定足数デバイスを指定する必要があります。
デュアルポート式のディスクを持つ、3 ノード以上のクラスタでは、必ずしもクラスタノードのすべてがディスクサブシステム全体にアクセスするわけではありません。そうした構成では、ディスクを共有するノードセットごとに定足数デバイスを 1 つ指定する必要があります。
Sun Cluster 構成では、クラスタを構成する全ノードに Sun StorEdge A5000 などのディスク記憶装置を接続できます。この構成により、OPS などのアプリケーションは 3 つ以上のノードからなるクラスタ上で動作することができます。このように、クラスタの全ノードに物理的に接続されたディスク記憶装置は直接接続デバイスと呼びます。この種のクラスタでは、直接接続デバイスから 1 つの定足数デバイスを選択する必要があります。
直接接続デバイスを持つクラスタでは、クラスタインターコネクトで問題が発生すると、次のいずれか 1 つのことが発生します。
定足数デバイスが設定されていて、手動介入が指定されている場合は、すべてのノードがユーザーの介入を求めます。
定足数デバイスが設定されていて、自動選択が指定されている場合は、最高または最小の ID を持つノードによって定足数デバイスが予約され、他のすべてのノードはユーザーの介入を求めます。
全ノードに対する直接接続デバイスを持たないクラスタの場合、定義では、複数の定足数デバイス (ディスクを共有するノードペアごとに 1 つ) が存在することになります。この構成では、2 つのノードが残って、その 2 つのノードが同じ定足数デバイスを共有する場合にのみ、定足数デバイスがその役割を果たします。
ノードに障害が発生した場合は、定足数デバイスを予約することができるノードが、クラスタの唯一のノードとして残ります。共有ディスク上のデータの完全性を維持するには、このようなノードが必要です。
Sun Cluster 環境に既存のデータを移行する方法を作成するにあたっては、次のことを考慮してください。
データを含む既存のディスクを接続することによって、Sun Cluster 構成にデータを移動することはできません。データを移行する前に、ボリューム管理ソフトウェアを使用して、ディスクを準備する必要があります。
ufsdump(1M) と ufsrestore(1M)、あるいはその他の適切なファイルシステムバックアップ製品を使用して、UNIX ファイルシステムのデータを Sun Cluster ノードに移行することができます。
Sun Cluster 構成の多重ホストディスクにデータを読み込む前に、データバックアップ計画を立ててください。Solstice BackupTM または ufsdump を使用して、Sun Cluster 構成をバックアップすることを推奨します。
Online:BackupTM と Solstice Backup の間に互換性はないため、バックアップ方法を Online:Backup から Solstice Backup に変更する場合は、特別な注意が必要です。システム管理者が第 1 に決定すべきことは、Solstice Backup を使用するようになった後で、Online:Backup でバックアップしたファイルをオンラインで利用できるようにするかどうかということです。バックアップ方法の変更についての詳細は、Solstice Backup のマニュアルを参照してください。
システムの構成を完了して、動作し始めたら、次のファイルを保存してください。クラスタで問題が発生した場合に、クラスタの問題をデバッグし、解決するのに役立つことがあります。
did.conf /etc
このファイルには、Solstice DiskSuite 構成のディスク ID (DID) マッピング情報が含まれます。この情報を使用して、ノードで重大な障害が発生した場合に正しい DID 設定になっているか追跡、確認することができます。
ccd.database /etc/opt/SUNWcluster/conf
このファイルには、重要なクラスタ構成情報が含まれます。『Sun Cluster 2.2 のシステム管理』の CCD の障害追跡に関する節の、このファイルの保存方法に関する説明を参照してください。
cluster_name.cdb /etc/opt/SUNWcluster/conf
このファイルには、クラスタ構成に関する現在の情報が含まれます。この情報は、元の構成をしてから発生した変更を判断する参考資料として利用できます。
metastat -s diskset_name -p > sav.diskset_name
このコマンドは、現在の Solstice DiskSuite ディスクセット構成を保存します。
Solaris は、ローカルの CD-ROM から、あるいは JumpStart を使用してネットワークインストールサーバーからインストールできます。複数のマシンに Solaris をインストールする場合は、ネットワークインストールを検討してください。それ以外の場合は、ローカルの CD-ROM を使用してください。
主パブリックネットワークとして FDDI を使用している構成の場合、JumpStart を使用して直接、ネットワークインストールを行うことではできません。これは、FDDI ドライバが提供されていないため、"mini-unix" で利用できないためです。主パブリックネットワークとして FDDI を使用している場合は、CD-ROM から Solaris をインストールする必要があります。
Sun Cluster 2.2 を使用するには、フレームワークあるいは HA データサービスのどちらのライセンスも必要ありません。また、Solstice DiskSuite や Cluster Volume Manager を実行するライセンスも必要ありません。ただし、SPARCstorage Array または StorEdge A5000 以外の記憶装置に対して SSVM を使用する場合は、そのライセンスが必要になります。SPARCstorage Array と StorEdge A5000 には、SSVM 用のライセンスが含まれています。必要な SSVM ライセンスについては、Sun License Center にお問い合わせください。詳細は、http://www.sun.com/licensing/ を参照してください。
DBMS 製品やサン以外の製品のライセンス取得が必要になることがあります。サン以外の製品のライセンスについては、その購入先にお問い合わせください。
この節では、確実に Sun Cluster 構成の可用性を高めるのに役立つ規則を説明します。これらの規則はまた、Sun Cluster 構成に適切なハードウェアを決定するのにも役立ちます。
構成によりますが、一般に、Sun Cluster ノードのハードウェア構成は同じにしてください。このことは、クラスタノードの 1 つを 2 枚の FC/S カードで構成した場合は、クラスタ内の他のすべての Sun Cluster ノードも FC/S カード 2 枚の構成にすることを意味します。
ノードごとに冗長なハードウェアを特定し、配置計画を立てて、1 つのハードウェア障害で両方のコンポーネントが失われないようにしてください。たとえば、Sun Enterprise 10000 システムに対するプライベートネットワークを検討する場合、最小構成は入出力ボード 2 つで、それぞれプライベートネットワーク接続の 1 つと多重ホストディスク接続の 1 つをサポートするようにします。このような構成にすれば、入出力ボードでローカルに障害が発生しても、両方のプライベートネットワーク接続や両方の多重ホストディスク接続が影響を受ける可能性が少なくなります。
この構成は、常に可能なわけではありませんが (構成によっては、システムボードが 1 枚だけのこともあります)、問題点のいくつかは、ハードウェアオプションを使用することによって対処できます。たとえば、SPARCstorage Array を 2 つ持つ Sun Enterprise 2 Cluster の構成では、プライベートネットワークの一方を Sun Quad FastEthernetTM Controller カード (SQEC) に接続し、もう一方をオンボードのインタフェースに接続できます。
RAID5 構成を使用しない場合は、Sun Cluster 構成では、あらゆる多重ホストディスクをミラー化する必要があります。ミラー化することにより、構成は単一ディスク障害に耐えることができます。
多重ホストディスクをミラー化するにあたっては、次のことを考慮してください。
ミラーまたはプレックスのサブミラーは、それぞれ異なる多重ホストディスク拡張装置に分散してください。
ミラー化すると、2 倍のディスク空間が必要になります。
Solstice DiskSuite、Sun StorEdge Volume Manager、Cluster Volume Manager は、3 方向のミラー化をサポートしています。ただし、Sun Cluster が必要とするのは、2 方向のミラー化だけです。
Solstice DiskSuite では、ミラーは連結やストライプなどの他のメタデバイスで構成されます。大規模な構成では、大量のメタデバイスが含まれることがあります。たとえば、UFS ロギングファイルシステムごとに 7 つのメタデバイスが作成されます。
異なるサイズのディスクにミラーを作成した場合、ミラーの容量は、最小のサブミラーまたはプレックスのサイズに制限されます。
最高の可用性を得るには、ローカルディスク上のルート (/)、/usr、/var、/opt、swap をミラー化してください。Sun StorEdge Volume Manager または Cluster Volume Manager では、このことは、ルートディスクをミラー化し、生成されたサブディスクをミラー化することを意味します。ただし、Sun Cluster では、ルートディスクのミラー化が必須というわけではありません。
リスク、複雑さ、コスト、保守時間の面からルートディスクに関するさまざまな方法を検討してください。どの構成にも当てはまるものはありません。ルートをミラー化するかどうかを決定するにあたっては、ご購入先に相談してください。
ルートのミラー化方法については、ボリュームマネージャのマニュアルを参照してください。
ルートファイルシステムをミラー化するかどうかを決定するにあたっては、次のことを考慮してください。
ルートをミラー化すると、システム管理の複雑さが増し、シングルユーザーモードでの起動が複雑になります。
ルートをミラー化するかどうかに関係なく、ルートは定期的にバックアップしてください。ミラー化だけで、管理上の誤りが防げるわけではありません。誤って変更あるいは削除したファイルは、バックアップによってのみ復元できます。
Solstice DiskSuite の構成で、メタデバイス状態データベースの定足数が失われるという障害が発生した場合は、保守を行わない限り、システムを再起動できなくなります。
Solstice DiskSuite のマニュアルのメタデバイス状態データベースとメタデバイス状態データベースの複製の説明を参照してください。
独立したコントローラにルートをミラー化するという方法は、最高の可用性を得る手段の 1 つです。
兄弟ノードをミラーと見なし、ローカルディスクドライブに障害が発生した場合にテイクオーバーが行われるようにすることができます。この場合は、ディスクが回復したときに、兄弟ノードのルートディスクからデータをコピーして、復元できます。
ただし、Sun Cluster ソフトウェアに即時テイクオーバーを保証する機能はないことに注意してください。実際問題として、テイクオーバーがまったく行われないことも考えられます。たとえば、ディスクの一部セクターが不良で、特定のデータサービスに不可欠のファイルのユーザーデータ部分が存在すると仮定します。その場合、データサービスは起動して入出力エラーになりますが、Sun Cluster ノードは動作を継続します。
ミラーを起動可能なルートディスクに設定して、主起動ディスクで問題が発生した場合に、そのミラーから起動が行えるようにすることができます。
ミラー化されたルートがあると、主ルートディスクで問題が発生しても、二次 (ミラー) ルートディスクで動作を継続することができます。
電源を入れ直したために、あるいは一時的に入出力エラーであったために、後で主ルートディスクが正常に戻った場合、以降の起動は、OpenBootTM PROM の -boot-device フィールドに指定された主ルートディスクを使用して行われます。このとき、Solstice DiskSuite の再同期は行われません。再同期をするには、ドライブが正常に戻ったときに手作業が必要になります。
この状況では、手動の修復作業はありません。ドライブが単に、起動できる状態になっただけです。
二次 (ミラー) ルートディスク上のファイルに変更が加えられている場合、起動中に、その変更が主ルートデバイスに反映されることはなく、サブミラーは無効になります。たとえば、/etc/system に対する変更が失われることがあります (主ルートディスクが休止している間に、一部の Solstice DiskSuite 管理コマンドによって、/etc/system が変更されることがあります)。
起動プログラムは、起動がミラーまたは元の物理デバイスのどちらから行われているのかを検出しません。起動プロセスの途中 (メタデバイスが読み込まれた後) でミラー化はアクティブになります。これより前の時点では、サブミラーが無効になる問題が発生しやすくなっています。
ボリューム管理ソフトウェアを使用してルートをミラー化している状態で Solaris 環境を新しいバージョンにアップグレードするには、現在の Solaris のマニュアルには記載されていない作業が必要になります。現在の Solaris のアップグレード方法を、Sun Cluster が使用するボリューム管理ソフトウェアに対して使用することはできません。このため、Solaris をアップグレードする前に、ルートのミラーを 1 方向のミラーに変更する必要があります。また、使用しているボリュームマネージャごとに、別の作業が必要になります。詳細は、使用しているボリューム管理ソフトウェアのマニュアルを参照してください。
Solstice DiskSuite でルート (/) ファイルシステムをミラー化するかどうかを決定するにあたっては、次の方法を検討してください。この節の説明は、Sun StorEdge Volume Manager および Cluster Volume Manager 構成には当てはまりません。
独立したコントローラ上にルートをミラー化して、3 つあるコントローラにメタデバイス状態データベースの複製を分散させる。これは、最高の可用性を実現する方法です。この構成にするによって、ディスクとコントローラ両方の障害に耐えることができます。
Solstice DiskSuite でディスク媒体障害にだけ耐えるには、次の方法を検討します。
2 つ目のコントローラ上にルートディスクをミラー化して、メタデバイス状態データベースのコピーをコントローラの 1 つの 3 つ目のディスクに保持する。
または
同じコントローラ上にルートディスクをミラー化して、メタデバイス状態データベースのコピーを同じコントローラの 3 つ目のディスクに保持する。
これらの構成では、ディスク媒体に障害が発生した後も定足数が維持されるため、保守する前にシステムを再起動することができます。ただし、これらの構成では、1 つのディスクにメタデバイス状態データベースの複製を含むコントローラの障害以外のコントローラ障害に耐えられません。
2 つのディスクに複製を保持するコントローラで問題が発生した場合、定足数は失われます。
同じコントローラ上にルートディスクをミラー化して、両方のディスクにメタデバイス状態データベースの複製を格納する。この方法では、ディスク媒体の障害に耐えられますが、即時テイクオーバーは行われません。しかし、この構成では、障害発生後、半分以上のメタデバイス状態データベースの複製が使用できなくなるため、保守を終了するまでマシンを再起動することはできなくなります。
ルートディスクをミラー化しないで、dd(1) またはその他のユーティリティを使用し、ルートディスクで問題が発生したときに起動に使用できる 2 つ目のディスクに、毎日手動でルートディスクをバックアップする。この方法では、OpenBoot PROM に 2 つ目のディスクを代替起動デバイスとして設定します。dd(1) の使用後は、ルートパーティションの変更を反映させるために、/etc/vfstab ファイルの更新が必要になることがあります。2 つ目のディスクのスライス 4 に追加のメタデバイス状態データベースの複製を設定してください。1 つ目のディスクに障害が発生した場合、それらの複製は、引き続き多重ホストディスクの複製を指定します。手動でメタデバイス状態データベースをコピーして、復元しないでください。複製は、Solstice DiskSuite で行なってください。
この節では、Sun Cluster の構成上の制限事項について説明します。
サービスとアプリケーションに関する次の制限事項に注意してください。
Sun Cluster は、それ自身が提供するデータサービスあるいは Sun Cluster データサービス API を使用して構成されたデータサービスに対してのみサービスを提供できます。
Sun Cluster 環境で sendmail(1M) はサポートされていないため、Sun Cluster のノードをメールサーバーとして構成しないでください。Sun Cluster のノードにメールディレクトリが存在してはなりません。
Sun Cluster システムをルーター (ゲートウェイ) として構成しないでください。システムが停止した場合、クライアントが代替ルーターを探して、回復することはできません。
Sun Cluster システムを NIS または NIS+ サーバーとして構成しないでください。ただし、NIS または NIS+クライアントとして構成することはできます。
Sun Cluster 構成を使用して、クライアントシステムに可用性の高い起動サービスあるいはインストールサービスを提供することはできません。
Sun Cluster HA for NFS に関する次の制限事項に注意してください。
Sun Cluster ノード上で、Sun Cluster HA for NFS にローカルにアクセスするアプリケーションを実行しないでください。たとえば、NFS によってエクスポートされた Sun Cluster ファイルシステムに Sun Cluster システムからローカルにアクセスしないでください。これは、ローカルロックによって、lockd(1M) の終了と再起動ができなくなるためです。終了して、再起動するまでの間に、ブロックされたローカルプロセスにロックが付与され、これにより、クライアントマシンがロックを再利用できなくなります。
Sun Cluster で、Sun Cluster HA for NFS リソースのクロスマウントを行うことはできません。
Sun Cluster HA for NFS では、NFS クライアントは必ずハードマウントする必要があります。
Sun Cluster HA for NFS では、論理ホストに対してホスト名の別名を使用しないでください。NFS クライアントが論理ホストのホスト名の別名を使用して HA ファイルシステムをマウントすると、statd ロックの回復で問題が発生することがあります。
Sun Cluster は、Secure NFS および、NFS での Kerberos の利用をサポートしていません。具体的には、share_nfs(1M) に対して -secure や -kerberos オプションを使用することできません。
ハードウェアに関する次の制限事項に注意してください。
Sun Cluster ノードのペアには、少なくとも 2 つの多重ホストディスク格納装置が必要です。これに対する例外は、Sun StorEdge A3000 ディスクを使用する場合であり、この場合、拡張装置は 1 つだけでかまいません。
Sun Cluster 2.2 と Solaris 7 の組み合わせで、SS1000 および SC2000 ハードウェアプラットフォームを使用することはできません。これらプラットフォームは、Solaris 2.6 では使用することができます。これは、Solaris 7 で SFE 1.0 の be(7D) ドライバがサポートされなくなったためです。このドライバは、SS1000 および SC2000 マシン上のクラスタインターコネクトに使用されます。
次の制限事項は、Ultra 2 シリーズの構成にだけ適用されます。
別の基本ハードウェア構成に移行するには、Sun Cluster ノードをインストールし直す必要があります。たとえば、FC/S カード 3 つと SQEC カード 1 つの構成から、FC/S カード 2 つと SQEC カード 1 つ、SFE または SunFDDITM カード 1 つの構成に移行するには、Sun Cluster ノードをインストールし直す必要があります。
FC/S カードに対するデュアル FC/OM は、SFE または SunFDDI カードと組み合わせる場合にのみサポートされます。
SFE または SunFDDI 0 カードの構成でデュアル FC/OM FC/S カードに障害が発生した場合は、ミラー化あるいはホットスペア処理によってではなく、フェイルオーバーによって回復モードになります。
Solstice DiskSuite に関する次の制限事項に注意してください。
メディエータを使用する Solstice DiskSuite の構成では、ディスクセットに設定するメディエータホスト数は偶数である必要があります。
Solstice DiskSuite 製品の RAID5 機能を使用することはできません。RAID5 は、Sun StorEdge Volume Manager あるいは Cluster Volume Manager でサポートされます。Sun StorEdge A3000 ディスク拡張装置を使用した場合は、ハードウェア方式の RAID5 もサポートされます。
クラスタ全体を停止させる電源障害が発生した場合、クラスタを再起動するには、管理者が介入する必要があります。管理者は、/var/adm/messages の内容を調べることによって最後に停止したノードを特定し、そのノードに対して scadmin startcluster を実行する必要があります。その他のクラスタノードに対しては scadmin startnode を実行して、クラスタをオンラインに戻します。
Sun Cluster ノード上でクライアントアプリケーションを実行しないでください。ローカルのインタフェースグループ構文のため、論理ホストのスイッチオーバーまたはフェイルオーバーによって、TCP (telnet/rlogin) 接続が切断されることがあります。クラスタのサーバーホストによって開始された接続だけでなく、クラスタ外部のクライアントホストによって開始された接続も切断されます。
Sun Cluster ノード上でシェルを使って /logicalhost ディレクトリにアクセスしないでください。スイッチオーバーまたはフェイルオーバーが試みられているときに /logicalhost ディレクトリにシェル接続すると、スイッチオーバーまたはフェイルオーバーができなくなります。
Solstice DiskSuite の growfs(1M) コマンドを使用して、Sun Cluster HA 管理ファイルシステムを大きくすることはできません。
論理ネットワークインタフェースは、Sun Cluster 用に予約されます。
Sun Prestoserve はサポートされていません。Prestoserve は、そのホストシステム内でのみ動作します。このことは、スイッチオーバーが発生した場合、Sun Cluster の兄弟ホストからは、Prestoserve メモリー上のいかなるデータも利用できなくなることを意味します。