前へ | 次へ | 目次 | 索引 |
StorageWorks RAID Array 210 または 230 サブシステムに RAID デバイスが接続されている場合,0 以外のノード割り当てクラスを使用すると,クラスタ環境で実行中にデバイス名の問題が発生することがあります。この場合は, RAID デバイスに $n$DRcu という名前が付けられます。ただし,n は (0 以外の) ノード割り当てクラスであり,c はコントローラ名, u はユニット番号です。
クラスタ内の複数のノードが同じ (0 以外の) ノード割り当てクラスを持ち,これらのノードに RAID コントローラが接続されている場合,異なる RAID デバイスに同じ名前 (たとえば $1$DRA0) が割り当てられることがあります。このような問題があると,データが壊れる可能性があります。
このような問題を防止するには, DR_UNIT_BASE システム・パラメータを使用します。このパラメータを使用すると,DR デバイスには,指定した DR_UNIT_BASE 値から順に番号が付けられます。たとえば,ノード割り当てクラスが $1,コントローラ名が A のときに,あるクラスタ・メンバの DR_UNIT_BASE を 10 に設定すると, RAID コントローラによって生成される最初のデバイス名は $1$DRA10 になり,次の名前は $1$DRA11,その次の名前は $1$DRA12 になります。
DR デバイス名が固有の名前になるようにするには,作成されるデバイス番号が重なり合わないように,各クラスタ・メンバで DR_UNIT_BASE の値を設定します。たとえば,3 つのクラスタ・メンバで DR_UNIT_BASE の値を 10,20,30 に設定することができます。各クラスタ・メンバに接続されているデバイスの台数が 10 台以下の場合は,DR デバイス番号は固有の値になります。
6.2.3 ポート割り当てクラスを使用する理由
ノード割り当てクラスが 0 以外の値の場合,デバイスが共用インターコネクトで接続されているかどうかとは無関係に,接続されているすべてのデバイスに対して,ノード割り当てクラスがデバイス名の接頭辞になります。クラスタ内で固有の名前を確保するには,デバイスがプライベート・バスにある場合でも,ディスク・デバイス名の ddcu の部分 (たとえば DKB0) が割り当てクラスの中で固有の値になるようにしなければなりません。
DIGITAL Storage Architecture (DSA) デバイスの場合,システム管理者は,固有の値になるように大きなユニット番号空間から適切な値を選択できるため,この制限はかなり簡単に回避できます。しかし,コントローラ名とユニット番号の両方をハードウェア構成で決定される SCSI のような他のデバイス・タイプの場合は,この制限の回避はもう少し困難です。
たとえば, 図 6-7 に示す構成では,各システムにアダプタ名 A のプライベート SCSI バスが接続されています。固有の名前を取得するには,ユニット番号が異なる値でなければなりません。このため,構成に含むことができるデバイスの最大数は 2 つのバスで最大 8 台になります (1 つ以上のバスでワイド・アドレッシングを使用できる場合は 16)。この結果,空の StorageWorks ドライブ・ベイが発生し,システムの最大記憶容量が小さくなってしまいます。
図 6-7 ノード割り当てクラスを使用する SCSI デバイス名
SCSI デバイス名の一部は,デバイスにアクセスするときに使用される SCSI コントローラによって決定されます (たとえば, DKBn の B)。したがって,各ノードが各デバイスに対して同じ名前を使用するようにするには,共用 SCSI バスに接続されているすべての SCSI コントローラで同じ OpenVMS デバイス名を使用しなければなりません。 図 6-7 では,各ホストはコントローラ PKB によって共用 SCSI バスに接続されています。
この要求を満たすには,共用 SCSI バスの構成が難しくなります。これは,システム管理者が SCSI コントローラ・デバイス名の割り当てに関して,ほとんどあるいはまったく制御できなくなるからです。特に,1 台以上のシステムに以下のものが接続されている場合,異なるシステム・タイプでコントローラ名を一致させるのは困難です。
ポート割り当てクラスには,以下の 2 つの利点があります。
SCSI,IDE,フロッピィ・ディスクおよび PCI RAID コントローラ・デバイスの名前を指定するときに,ポート割り当てクラスを使用すると, 第 6.2.2.9 項 , 第 6.2.3 項 および 第 6.2.3.1 項 で説明した構成の制約が解除されます。 第 6.2.2.9 項 にある DR_UNIT_BASE システム・パラメータを使用する必要はありません。各バスに固有の割り当てクラス値を与えることができるため,ディスク・デバイス名の ddcu の部分 (たとえば DKB0) がすべてのバスで固有の値である必要はなくなります。さらに,デバイス名の異なるコントローラを同じバスに接続できるようになります。これは,ディスク・デバイス名がコントローラ名に依存しないようになるためです。
図 6-8 は, 図 6-7 と同じ構成を示していますが,CHUCK という名前のホストと,左下の SCSI バスに追加ディスクが接続されている点が異なります。この図では,デバイス名でポート割り当てクラスが使用されています。共用される SCSI インターコネクトに対しては,ポート割り当てクラス 116 が使用されており,共用されない SCSI インターコネクトに対しては,ポート割り当てクラス 0 が使用されています。この構成でポート割り当てクラスを使用すれば,以下に示すように,これまで不可能だったことが可能になります。
図 6-8 ポート割り当てクラスを使用するデバイス名
ポート割り当てクラスは,1 つのインターコネクトに接続されているすべてのポートに対する指定です。ポート割り当てクラスは,デバイス名でノード割り当てクラスの代わりに使用されます。
ポート割り当てクラスには,以下の 3 種類があります。
3 種類のポート割り当てクラスにはそれぞれの命名規則があります。
6.2.4.1 マルチホスト・インターコネクトに接続されているデバイスのポート割り当てクラス
マルチホスト・インターコネクトに接続されているデバイスのポート割り当てクラスには,以下の規則が適用されます。
1 台のシステムに複数の DKA100 ディスクが接続される可能性があるため,省略名 (DK100 など) ではなく,完全に指定された名前 (たとえば $101$DKA100 や ABLE$DKA100 など) を使用することが重要になります。
表 6-4 に,この種のポート割り当てクラスを使用するデバイス名の例を示します。
デバイス名 | 説明 |
---|---|
$101$DKA0 | ポート割り当てクラスは 101 である。DK はディスク・デバイス・カテゴリを示し,A はコントローラ名, 0 はユニット番号である。 |
$147$DKA0 | ポート割り当てクラスは 147 である。DK はディスク・デバイス・カテゴリを示し,A はコントローラ名, 0 はユニット番号である。 |
6.2.4.2 シングルホスト・インターコネクトに接続されているデバイスのポート割り当てクラス 0
シングルホスト・インターコネクトに接続されているデバイスのポート割り当てクラス 0 には,以下の規則が適用されます。
ポート割り当てクラス 0 を使用するデバイス名の例を 表 6-5 に示しています。
デバイス名 | 説明 |
---|---|
ABLE$DKD100 | ABLE は,デバイスが接続されているノードの名前である。 D は接続されているコントローラの指定である。0 以外のポート割り当てクラスに対しては,コントローラ指定は A にならない。このデバイスのユニット番号は 100 である。$0$ というポート割り当てクラスはデバイス名に含まれない。 |
BAKER$DKC200 | BAKER は,デバイスが接続されているノードの名前であり,C は接続されているコントローラの指定であり,200 はユニット番号である。$0$ というポート割り当てクラスはデバイス名に含まれない。 |
ポート割り当てクラス -1 は,ポート割り当てクラスが使用されていないことを示します。この場合,ノード割り当てクラスが使用されます。コントローラ名は既定の名前から変更されません (システム構成に基づいて OpenVMS が割り当てます。ノード割り当てクラスの影響を受けません)。
6.2.4.4 ポート割り当てクラスの実装方法
ポート割り当てクラスは,OpenVMS Alpha バージョン 7.1 から登場し,OpenVMS VAX でサポートされています。 VAX コンピュータは,Alpha システムに接続されているディスクのうち,ポート割り当てクラスを使用しているディスクを名前でサービスできます。
ポート割り当てクラスを実装するには,以下の操作が必要です。
ポート割り当てクラスの使用を有効にするには,新しい SYSGEN パラメータ DEVICE_NAMING を 1 に設定しなければなりません。このパラメータのデフォルト設定は 0 です。さらに, SCSSYSTEMIDH システム・パラメータを 0 に設定しなければなりません。このように設定されているかどうか確認してください。
OpenVMS Cluster 構成プロシージャ,CLUSTER_CONFIG.COM (または CLUSTER_CONFIG_LAN.COM) を使用して,1 つ以上のポート割り当てクラスを割り当てることができます。
CLUSTER_CONFIG.COM または CLUSTER_CONFIG_LAN.COM を使用してポート割り当てクラスを割り当てることができない場合 (たとえば,プライベート・システム・ディスクからブートして既存のクラスタのメンバになる場合),新しい SYSBOOT SET/CLASS コマンドを使用できます。
以下の例では,新しい SYSBOOT SET/CLASS コマンドを使用して,既存のポート割り当てクラス 152 を PKB ポートに割り当てる方法を示しています。
SYSBOOT> SET/CLASS PKB 152 |
SYSINIT プロセスは,この新しい名前が後続のブートでも確実に使用されるようにします。
ポート割り当てクラスの割り当てを解除するには,クラス番号を指定せずに,ポート名を入力します。以下の例を参照してください。
SYSBOOT> SET/CLASS PKB |
ポートと割り当てクラスのマッピングは,標準テキスト・ファイルである SYS$SYSTEM:SYS$DEVICES.DAT に格納されます。 SYS$DEVICES.DAT を変更するには, CLUSTER_CONFIG.COM (または CLUSTER_CONFIG_LAN.COM) コマンド・プロシージャを使用するか,または特殊な場合は SYSBOOT を使用します。
6.2.4.5 SCSI インターコネクトに対するクラスタ単位のリブートの要件
デバイスの割り当てクラスを変更すると,デバイス名も変化します。クラスタ単位のリブートを行うと,すべてのノードが確実にデバイスを新しい名前で認識するようになります。つまり,通常のデバイス・ロックとファイル・ロックの状態が確実に一貫したものとなります。
デバイス名が変化したときに,必ずしもクラスタ全体をリブートする必要はありません。この後説明するように, SCSI バスを共用するノードだけをリブートすることができます。この操作が可能な条件と,その結果もここで説明します。
この操作が常に可能なわけではありません。特に,ノードでシステム・ディスクとして使用されているディスクをディスマウントすることはできません。ディスクがディスマウントされないと,新しいデバイス名を使用して同じディスクをマウントしようとしても,以下のエラーが発生します。
%MOUNT-F-VOLALRMNT, another volume of same label already mounted |
したがって,ディスクをディスマウントできないノードはリブートする必要があります。
これらのノードをリブートする前に,SCSI バスに接続されているディスクが,リブートされないノードでディスマウントされていることを確認してください。
OpenVMS では,SCSI バスの名前が,同じバスにすでにアクセスしている別のノードと異なる名前付けになる場合,ノードをブートできないようになっています (このチェックは,ステップ 1 のディスマウントのチェックとは無関係に行われます)。 |
元の名前でマウントされているディスクが他のノードにない場合は,新しい名前を使用してディスクをシステム単位またはクラスタ単位でマウントできます。新しいデバイス名は,互換性のあるソフトウェアを稼動しているすべてのノードで確認することができ,これらのノードもディスクをマウントし,通常のようにアクセスすることができます。
リブートされていないノードでは,新しいデバイス名だけでなく,古いデバイス名も表示されます。しかし,古いデバイス名を使用することはできません。古い名前でデバイスにアクセスすると,そのデバイスはオフラインになります。古い名前は,ノードをリブートするまで消去されません。
6.3 MSCP および TMSCP によってサービスされるディスクとテープ
MSCP サーバと TMSCP サーバは,ローカルに接続されているディスクおよびテープをすべてのクラスタ・メンバから利用できるようにします。ローカルに接続されているディスクとテープは,自動的にクラスタ全体でアクセスできるようになるわけではありません。これらのデバイスへのアクセスは,ディスクの場合は MSCP サーバ,テープの場合は TMSCP サーバを使用して,クラスタ・アクセス可能デバイスとして設定しない限り,ローカル・コンピュータに制限されます。
前へ | 次へ | 目次 | 索引 |