前へ

次へ

目次

索引

CIPCA アダプタは，PCI バス付きの AlphaServer，CI 接続の VAX ホスト・システム，ストレージ・コントローラ，CI スター・カプラ拡張機能によってサポートされています。

C.3.1 AlphaServer サポート

表 C-2 は，PCI バス付きの AlphaServer システムにおける CIPCA サポートを，各システムにサポートされている CIPCA 数の上限とともに示したものです。

表 C-2 CIPCA の AlphaServer サポート

システム	最大 CIPCA 数	備考
AlphaServer 8400	26	CIPCA アダプタと CIXCD アダプタを複合的に使用可能。上限は 26。OpenVMS バージョン 7.1 より前のバージョンでは，上限は 10。
AlphaServer 8200	26	OpenVMS バージョン 7.1 より前のバージョンでは，上限は 10。
AlphaServer 4000，4100	3	3 つの CIPCA を使用するとき，うち 1 つは CIPCA-AA とし，2 つを CIPCA-BA とすること。
AlphaServer 4000 と I/O 拡張モジュール	6	6 つの CIPCA を使用するとき，CIPCA-AA は上限 3。
AlphaServer 1200	2	OpenVMS バージョン 7.1-1H1 で最初にサポート。
AlphaServer 2100A	3
AlphaServer 2000，2100	2	CIPCA-BA は 1 つのみ。

C.3.2 CI 接続のホスト・システムの互換性

CI 接続のホスト・システムの場合，CIXCD や CIBCA-B を使用する OpenVMS VAX ホストは， CIPCA や CIXCD を使用する OpenVMS Alpha サーバ・ホストと同じく， CIPCA をサポートしています。つまり，CIPCA アダプタを使用する Alpha サーバが，CIXCD アダプタや CIBCA-B CI アダプタを使用する VAX システムと同じ CI バス上に共存できることを表します。

OpenVMS Cluster システムでサポートされているシステムの最大数は 96 であり，この値は CIPCA を 1 つ以上使用しても影響を受けません。ただし，CI ノード数の上限は 16 です ( 付録 C.3.4 項 参照)。

C.3.3 ストレージ・コントローラのサポート

CIPCA アダプタは，HSC50 を除くすべての HSC/HSJ コントローラと同じ CI バス上で使用できます。 表 C-3 にあるように，コントローラによっては，特定のファームウェアとハードウェアが必要なことがあります。

表 C-3 CIPCA をサポートするためのコントローラの要件

コントローラ	要件
HSJ30，HSJ40	HSOF バージョン 2.5 (またはそれ以降) ファームウェア
HSC40，HSC70	リビジョン F (またはそれ以降) L109 モジュール
HSJ80	ACS V8.5J (またはそれ以降) ファームウェア

C.3.4 スター・カプラ拡張機能のサポート

どのスター・カプラにも CI スター・カプラ拡張機能 (CISCE) を接続でき，これによって接続キャパシティを 32 ポートまで増強できます。スター・カプラには CPU を最大 16 まで接続できます。これはポート数とは関係ありません。

C.3.5 構成上の制限事項

構成時には以下の制限事項があります。

EISA スロット・リンク・モジュール・リビジョン A01 付きの CIPCA-AA

EISA スロット・リンク・モジュール・リビジョン A01 付きの CIPCA-AA の場合，アービトレーション・タイムアウト・エラーを避けるため，以下に示す DIP スイッチ設定を使用してください。CI 負荷が高い場合，アービトレーション・タイムアウト・エラーにより，CI パス・エラーと CI 仮想回路閉鎖が発生することがあります。

CIPCA-AA リンク・モジュールにおけるDIP スイッチ設定では，クラスタ・サイズとノード・アドレスを指定します。以下の設定は，リンク・モジュール・リビジョン A01 の DIP スイッチの設定だけに適用します。

• クラスタ・サイズを 16 に設定する場合，CI アダプタを，そのスター・カプラのノード・アドレス 15 に設定しないでください。

• クラスタ・サイズを 32 に設定する場合，CI アダプタを，そのスター・カプラのノード・アドレス 31 に設定しないでください。また，CIPCA をノード・アドレス 0 に設定したり，CI アダプタをノード・アドレス 16 に設定しないでください。

以上の制限事項は，EISA スロット・リンク・モジュール・リビジョン B01 以上と， CIPCA-BA の PCI スロット・リンク・モジュールには適用しません。

4K CI パケットを使用するときの HSJ50 ファームウェアの要件

HSJ50 ファームウェアがバージョン 5.0J-3 以降でない限り，HSJ50 コントローラによる 4K CI パケットの使用を有効にしないでください。HSJ50 ファームウェアのバージョンがバージョン 5.0J-3 より前のままで，4K CI パケットを有効にすると，データが壊れることがあります。HSJ50 ファームウェアがこの要件に合わない場合は，弊社のサポート担当者にお問い合わせください。

C.4 インストールの要件

CIPCA アダプタをクラスタにインストールするときは，以下のバージョン別の要件に従ってください。

C.4.1 BAP (Bus Addressable Pool) サイズの管理

CIPCA，CIXCD，KFMSB の各アダプタはバス・アドレス指定可能なプール (BAP) を使用します。OpenVMS バージョン 7.1 以降，AUTOGEN で BAP の割り当てを管理するようになりました。オペレーティング・システムのインストールやアップグレードをした後は， FEEDBACK 修飾子を指定して AUTOGEN を実行してください。こうして AUTOGEN を実行すると，以下の 4 つのシステム・パラメータが設定されます。

• NPAG_BAP_MIN

• NPAG_BAP_MAX

• NPAG_BAP_MIN_PA

• NPAG_BAP_MAX_PA

BAP の割り当てサイズは，アダプタ・タイプ，アダプタ数，オペレーティング・システムのバージョンによって異なります。 表 C-4 に示すように，物理メモリのサイズにより，BAP が独立したままになるか，標準の非ページ対応動的メモリ (NPAGEDYN) とマージされるかが決まります。

表 C-4 アダプタ・タイプと OpenVMS バージョンによる BAP の割り当て

アダプタ	バージョン 7.1	バージョン 7.2	独立した BAP またはマージされた BAP
CIPCA	4 MB	2 MB	物理メモリ >1 GB の場合，独立; それ以外はマージ
CIXCD	4 MB	2 MB	物理メモリ >4 GB の場合，独立; それ以外はマージ
KFMSB	8 MB	4 MB	物理メモリ >4 GB の場合，独立; それ以外はマージ

非ページ対応のプールにマージした BAP の場合，非ページ対応のプールの初期サイズと最大サイズ (DCL コマンド SHOW MEMORY/POOL/FULL で表示) は，SYSGEN パラメータ NPAGEDYN と NPAGEVIR の値と一致しませんが，SYSGEN パラメータ NPAG_BAP_MIN の値を NPAGEDYN に足すと，初期サイズになり，NPAG_BAP_MAX の値を NPAGEVIR に足すと，最大サイズになります。

OpenVMS システムには，これらの SYSGEN パラメータの合計値ほどのマージ・プールが不要なこともあります。システムを 2，3 日走らせた後，FEEDBACK 修飾子を指定して AUTOGEN を実行し，マージ済みの非ページ対応プールに割り当てられたメモリ・サイズを微調整してください。

C.4.2 OpenVMS バージョン 6.2-1H2 と OpenVMS バージョン 6.2-1H3 における AUTOCONFIGURE の制限事項

通常のインストール・ブートを実行すると，SYSMAN で無効になっていなければ， AUTOCONFIGURE は自動的に実行します。AUTOCONFIGURE は SYS$STARTUP: VMS$DEVICE_STARTUP.COM (SYS$SYSTEM:STARTUP.COM から呼び出し) から実行します。 OpenVMS バージョン 6.2-1H2 または OpenVMS バージョン 6.2-1H3 を実行するとき，ブート・シーケンスをカスタマイズしている場合，AUTOCONFIGURE が実行するか確認してください。実行しない場合は，SYSTARTUP_VMS.COM を終了する前にすべての CIPCA デバイスを再構成してください。

C.5 CIPCA エラー解析のための DECevent

エラー・ログ・ファイルで CIPCA エラーを調べるには，DECevent を使用します。 DCL コマンド ANALYZE/ERROR_LOG は，サポート CIPCA や他の新しいデバイスをサポートするためのアップデートがまだ済んでいません。このコマンドを使用すると，エラー・ログ・エントリが正しくフォーマットできないことがあります。

OpenVMS Alpha CD-ROM で提供される DECevent をインストールします。以下の DCL コマンドにより，DECevent を呼び出してダンプ・ファイルを解析します。

• DIAGNOSE --- 現在のシステム・エラー・ログ・ファイルを解析します。

• DIAGNOSE filename --- エラー・ログ・ファイル filename.sysを解析します。

DECevent の使用方法の詳細については，DCL HELP DIAGNOSE コマンドを実行して確認してください。

C.6 パフォーマンス対策

CIPCA は，従来の非同期アービトレーション・アルゴリズムの代わりに，同期アービトレーションという最適化が強化された新しい CI アービトレーション・アルゴリズムを使用します。2 つのアルゴリズムは完全に互換性があります。CI が飽和状態の場合，新旧両方のアルゴリズムは等価であり，すべてのノードに対して公正なラウンド・ロビン方式のアクセスを提供します。ただし，トラフィックが少ない場合，新しいアルゴリズムには次のような利点があります。

• 平均 CI アービトレーション時間が短縮されたことでパケット伝送待ち時間も短縮。

• ノード間スループットが増加。

• 帯域幅を無駄にし，同期アービトレーション・ノードだけの構成における待ち時間を増加させる CI 衝突を排除。

• 同期アービトレーションと非同期アービトレーションの複合 CI ノードにより CI 衝突率を削減。削減量は，同期アービトレーション CI ノードが送信するフラクションにほぼ比例します。

同期アービトレーションのサポートは，HSJ コントローラ・ファミリでは潜在的な状態です。CIPCA コントローラと HSJ コントローラの両方を含む構成では，HSJ を有効にして同期アービトレーションを使用することをお勧めします。

上記の操作には以下の HSJ CLI コマンドを使用します。

CLI> SET THIS CI_ARB = SYNC

このコマンドの結果は，HSJ をリブートすると有効になります。

C.6.2 HSJ50 および HSJ80 による CIPCA パフォーマンスの強化

HSJ50 または HSJ80 コントローラで CIPCA アダプタのパフォーマンスを強化するには，HSJ50 または HSJ80 で 4K CI パケットを使用可能にするのが効果的です。HSJ50 の場合は，ファームウェア・リビジョンのレベルがバージョン 5.0J-3 以降でなければなりません。HSJ80 の場合は，ファームウェア・リビジョンのレベルがバージョン ACS V8.5J 以降でなければなりません。

4K CI パケットの使用を有効にするには，HSJ50 または HSJ80 コンソール・プロンプトに以下のコマンドを指定します。

CLI> SET THIS_CONTROLLER CI_4K_PACKET_CAPABILITY

このコマンドの結果は HSJ50 をリブートすると有効になります。

ここでは，マルチサイト OpenVMS Cluster 構成について説明します。ここで説明するマルチサイト OpenVMS Cluster 構成では，約 40 km から 200 km という遠距離を隔てて分散したサイトに，複数のノードが配置されています。この構成方法は， OpenVMS バージョン 6.2 から導入されたものです。一般的な構成方法とともに，複数のサイトを接続するための 3 つのテクノロジについて説明します。マルチサイト・クラスタの利点は，他の参考資料からの引用とともに参照先も紹介します。

この付録の内容は，『Multiple-Site VMScluster Systems』追補マニュアルの内容を更新したものです。

D.1 マルチサイト OpenVMS Cluster システムとは?

マルチサイト OpenVMS Cluster システムは，メンバ・ノードが物理的に分散して配置された OpenVMS Cluster システムです。使用テクノロジにより，接続距離が約 240 km を超える場合があります。

遠距離を隔てて拠点が分散した組織では，マルチサイト OpenVMS Cluster システムを利用すれば，OpenVMS Cluster システムの利点を活かすことができます (たとえば，データをサイト間で共用し，データ・センター・オペレーションは， 1 個所に一元化するなど)。

図 D-1 は，製造拠点をワシントン D.C. に持ち，本社がフィラデルフィアにあるマルチサイト OpenVMS Cluster システムの概念を表しています。この構成におけるサイト間の物理的な距離は約 210 km あります。

図 D-1 フィラデルフィアとワシントン間のサイト間リンク

以下のサイト間リンクのテクノロジは，OpenVMS VAX システムと OpenVMS Alpha システムに認定されています。

• 非同期転送モード (ATM)

• DS3

• FDDI

高度なパフォーマンスを実現するローカル・エリア・ネットワーク (LAN) テクノロジを ATM，DS3，FDDI の各インターコネクトと組み合わせれば，ワイド・エリア・ネットワーク (WAN) 通信サービスを OpenVMS Cluster 構成で利用できます。 GIGAswitch クロスバー・スイッチと ATM，DS3，または FDDI インターコネクトで構成した OpenVMS Cluster システムでは，ノード同士が何キロメートルも離れていても使用できます。(2 個所のサイト間の実距離は，サイト間の直線距離ではなく，サイト間のケーブル経路の長さです。) 付録 D.3 節 では，OpenVMS Cluster システムと WAN 通信サービスをさらに詳しく説明します。

マルチサイト OpenVMS Cluster システムには，次のような長所があります。

長所	説明
リモート・サテライトとノード	図 D-2 に示すように，二次サイトにリモート・サイトを少数配置でき，それらを一元管理できるだけでなく，一次サイトのリソースも利用できます。たとえば，サイト固有デバイスに直接関連付けられた倉庫や小規模工場に，本社のデータ・センターをリンクすることができます。あるいは，一次ビジネス・サイトから都市のビジネス街に数個のエンジニアリング・ワークステーションをインストールすることができます。
データ・センターの管理強化	1 つの管理チームで複数のサイトのデータ・センターにあるノードを管理できます。
リソースの物理的な共用	大容量のコンピュータ，テープ・ライブラリ，ディスク・アーカイブ，フォトタイプセッタなどのデバイスを，複数のサイトで簡単に共用できます。
リモート・アーカイブ	クラスタの任意の場所にあるアーカイバル媒体のバックアップを作成できます。たとえば，一般には，1 個所にディスクやテープを用意してマルチサイト OpenVMS Cluster 内のすべてのサイトのデータをバックアップします。リモート・サイトのデータのバックアップは透過的に処理されます (つまり，リモート・サイトで人が操作する必要はありません)。
強化された可用性	一般に，マルチサイト OpenVMS Cluster は， LAN OpenVMS Cluster の可用性の利点をすべて備えています。また，マルチサイト OpenVMS Cluster 構成では遠距離にある複数のサイトを接続して，さまざまな方法でシステムやシステム要素の可用性を強化します。 論理ボリューム/データの可用性---ボリューム・シャドウイングや RAID (redundant array of independent disks) を利用すると，両サイトにメンバを配置した論理ボリュームを作成できます。両方のサイトのどちらかが利用できなくなっても，残ったサイトのデータは利用できます。 サイト・フェールオーバ---サイトのどれかに障害が発生した場合や，他のサイトとの通信が途絶えたときに自動的に処理を続行するためのサイトを選択するには，VOTES システム・パラメータを調整します。 ディザスタ・トレランス---Disaster Tolerant Cluster Services for OpenVMS が提供するソフトウェア，サービス，管理手順と組み合わせると，高度なディザスタ・トレランスが可能です。詳細については，弊社のサービス担当者にお問い合わせください。

図 D-2 は，リモート・サイトからアクセスできるサテライトを備えた OpenVMS Cluster システムです。

図 D-2 リモート・サテライトを備えたマルチサイト OpenVMS Cluster 構成

前へ

次へ

目次

索引