本書について

コンソール管理機器への需要は、インターネットや企業アプリケーションに必要な処理能力に達するためのクラスターとサーバー・ファームの利用が増加しているため上昇しています。

本書ではコンソール・ポート管理（サーバーおよびネットワーク機器をシリアル・コンソール・ポートから帯域外管理する）について説明し、インテリジェント製品の選択、ソリューションの設計と実装に関する情報を記載しています。

コンソール・ポートと帯域外管理

サーバーとネットワーク機器はデータ送信に使用されるチャンネルと同じチャンネル（通常イーサネットLAN）から、利用できる多くの管理ツールを使用して管理できます。これは最も一般的な管理形式で、帯域内ネットワーク管理と呼ばれています。

帯域内管理のほかに、弊社の機器には低レベルの制御が必要な場合があります。たとえば、特定のサーバーに対してハードウェアのセルフテストとBIOS情報を監視するとします。この情報は、オペレーティング・システムがロードされる前に生成されるので、この情報を取得するのにネットワーク接続を頼りにすることはできません。このため、帯域外管理（データ送信に使用されるチャンネルとは別の、専用の管理チャンネルを使用）が必要になります。

私たちがその場にいてサーバーが数台ある場合は、帯域外管理はGUIまたはテキストベース・インターフェイスを使用してサーバー・コンソールで個別に実行できます。

帯域外管理についての別の重要な観点は、ネットワークに接続のボックスとサーバーの管理をネットワークに依存することは、必ずしも有効ではないということです。ネットワークを中断をさせる問題を解決するためにノードにアクセスしてトラブルシューティングを実行する方法はあるでしょうか。もう一度いいます。帯域外管理がその答えです。

大部分のUNXサーバー（Linux、FreeBSD、Solaris、HP/UX、AIX、System Vなど）はシリアル・コンソール・ポートを介して監視され、管理されます。コンソールから、システム管理者は診断情報（ブート・メッセージ、エラー・ログ、アラーム、モニター・モード）へのアクセス、低レベルのシステム構成の変更、その他の管理タスク（システムのリセットや再起動など）の実行が可能になります。

物理ネットワーク・インターフェイスのほかに、ネットワーク機器（ルーター、スイッチ、アクセス・サーバー）には通常別の帯域外管理と設定ポート（コンソールまたは補助ポート）があります。

サーバーのコンソール・ポートとネットワーク機器はRS-232インターフェイスを使用します。これらに接続するには、シリアル・ケーブルとASCII端末（または、HyperTerminalやKermiなど、PCが動作するターミナル・エミュレーション・ソフトウェア）が必要です。

コンソール・アクセス・サーバーとは

ネットワーク内のサーバーとボックスの数が増え、数個のノード以上になると、ボックスごとに1つの管理コンソールをあてることは実用的でなくなります。端末を別の端末に移動することなくすべてのコンソール・ポートにアクセスしたい場合があります。コンソール・アクセス・サーバー（CAS）は、システム管理者が1つのコンピューター・ネットワークまたはサーバー・ファームにあるすべてのコンソール・ポートに単一のステーションから便利にアクセスできるようにする機器です。

CASを使用するもう一つの理由は、コンソール・ポートをリモートでアクセスする必要があることです。コンソール管理ソリューションは、インターネットやダイアルアップ接続を使用して、LANを通じてまたはリモートでどこからでも、いつでもローカルにコンソールにアクセスできなければなりません。

コンソール・アクセス・サーバーには複数のRS-232シリアル・ラインがあり、これを使用してコンソール・ポートや少なくとも1つのイーサネットLANポートに接続してネットワークに接続します。CASはアクセスが簡単、迅速、便利になるような接続性と、侵入者を締め出すセキュリティを提供します。

より重要な業務のアプリケーションが単一の大きなメインフレームよりもサーバー・ファームで実装されるほど、コンソールは大型コンピューターをインストールする場合に不可欠な要素になります。

適切なコンソール・アクセス・サーバーの選択

コンソール・アクセス・サーバーで必要な機能の一覧を次に表示します。これらの項目の一部について詳細は、本書の後半に記載されています。

• スケーラビリティとポート密度 - データ・センターのラック・スペースは値が張るため、最小スペースで最大ポート数を所有することが重要です。市販されている製品では、シャシー当たりの最大ポート数は16または64です。一部の製品では、複数のボックスを積み上げより大きな仮想ボックスを作成することができます。通常のポート密度はラック・スペース1Uあたり8から16ポートで、もっとも高い密度は32ポート/1U（1Uは、標準の17インチ・ラックで高さ1.75インチに相当）です。
• 機械的特性 - コンソール・アクセス・サーバーはお使いのラックおよびケーブル管理システムに上手く統合する必要があります。内蔵のRJ-45コネクター、最小限に抑えた外部ケーブル、可動部品がないこと、高レベルな統合、フロント・パネルLEDステータス・インジケーター、統合電源装置は、望ましい機能の例です。一部の製品では外部ケーブルの見栄えが良くなかったり、ラックに収納しにくいものがあります。
• セキュリティと接続性 - サーバーとルーターのコンソール・ポートへのアクセス権を取得するユーザーは、潜在的にネットワーク全体を制御できます。IP PacketとService Filtering、RADIUS Socket Authentication、Secure Shell（SSH）などのセキュリティ機能が重要です。CASはシステム管理者にとって簡単、迅速、便利なアクセスであるはずですが、侵入者を排除する能力が必要になります。インターネット、LAN、およびダイアルアップ接続に完全に対応しなければなりません。インターネット時代以前からの旧式の製品には、今日のネットワークに求められるセキュリティまたはインターネット接続性がありません。
• 機能性およびフレキシビリティ - CASとして販売されている一部のノーブランドのターミナル・サーバー製品には、適正にコンソール・ポートを管理するための機能がありません。CASはシリアル・ポートへのダイレクトTelnetやSSHをサポートし、複数のポート・アドレス法（IPアドレス、TCPポート番号、またはメニューでの手動選択）が使用できなければなりません。ローカルまたはサーバー・ベースの認証が可能でなければなりません。RS-232信号伝達を完全にサポートして、意図的ブレイク信号を送信し、意図的でないブレイク信号を生成しません。メッセージのログを許可します。選択された製品によっては、機能性をユーザー独自のニーズにカスタマイズできる場合があります。
• コストとサービス - ベンダーのコンソール管理に関する意識と知識によっては、装置の費用および製品とともに提供されるサービスの質に大きなばらつきが見られる場合があります。購入する前に、ベンダー側が一般的にネットワーク、特にコンソール・アクセスを理解し、製品にはモデム設計があること、対費用効果が高いこと、ソフトウェアをダウンロードにより更新できることなどを理解しているか確認する必要があります。

既存の製品を見ると、次の3つの明確なカテゴリーの確認が可能です。

従来のコンソール・アクセス・サーバー

コンソール・ポート管理は新しいアプリケーションではありません。複雑すぎるハードウェアを使用して費用が高くなるだけでなく、従来のコンソール・アクセス製品はサーバー・ファームのサイズの増大とインターネット接続のニーズにより求められる変化に追従することができませんでした。これらはソフトウェア・ベースのスケーラビリティとモジュラリティよりもハードウェアに重点を置き、接続性とセキュリティ機能は貧弱です。Lightwave Console Server 3200は従来のCASの一例です。

ノーブランドのターミナル・サーバー

ターミナル・サーバーはシリアル端末をUnixシステムに接続するために使用されました。これらの製品の一部はコンソール・アクセス機能に適応させるためソフトウェアの機能を統合しました。これらの製品は通常強力なインターネット接続とセキュリティ機能が搭載されていますが、特定のコンソール機能（便利なケーブル配線、高いポート密度、ポートの状態の視認装置、意図的でないブレイク信号を防止するための特定のハードウェアなど）がありません。Cyclades-PR3000/TS、Lantronix、Portmaster 2、Xyplex、Cisco 2511はコンソール・アクセス・サーバーとして使用できるノーブランドのターミナル・サーバーです。

PCベースのターミナル・サーバー

PCハードウェアやLinux、FreeBSDなどのオープン・ソースのオペレーティング・システムを使用して、PCにマルチポート・シリアル・ボードを取り付けることでターミナル・サーバーを設置することは、一部のユーザーにとって実行可能な計画になります。これらのソリューションはポート密度と統合では脆弱ですが、特定のニーズに対応するためのスケーラビリティとフレキシビリティに潜在的な利点があります。

市販されている製品間で目的別に比較したチャートが弊社のWebサイトでご覧になれます。

コンソール・ポート管理のCycladesソリューション

世界最大のインターネットおよび法人向けサーバー・ファームの中には、Cycladesコンソール管理製品を使用して管理ができるようになりつつあるものがあります。弊社ではサーバーベース・ソリューション向けにスタンドアロン型ソリューションとコンポーネントの両方を提供しています。これらの製品の特徴の一部を次に掲載しています（詳細はWebサイトをご覧ください）。http://www.cyclades.com

Cyclades-TS1000（16ポート）およびCyclades-TS2000（32ポート）

TS1000とTS2000はスタンドアロン・コンソール・アクセス・サーバーとターミナル・サーバーです。これらのサーバーは最高のポート密度（1Uラック・スペースに16または32ポート）を持ち、単一の内蔵ユニット内に完全に統合されます。RS-232インターフェイスはRJ-45コネクタに装備され、状態インジケータのフロント・パネルにチャンネルごとに3つのLEDランプが付いています。

TS1000とTS2000はコンソール管理アプリケーションを考慮して設計されています。ノーブランドのターミナル・サーバーからのセキュリティと接続性を、従来のコンソール・アクセス・サーバーの特定のコンソール・アクセス機能と組み合わせ、効果的、安全、対費用効果の高い製品にします。

Cyclades-Z（PCIアダプターに16から64 RS-232ポート）

Cyclades-ZはPCサーバー用のPCIマルチポート・シリアル・カードで、サーバーベースのコンソール・アクセス・ソリューションを構築するために使用できます。このカードはLinux、FreeBSD、またはWindowsのオペレーション・システムを動作するどの標準的なコンピューターにも取り付けることができ、RJ-45コネクターに16から64 RS-232インターフェイスを提供します（外部ボックス1Uあたり16ポート）。

CASの動作

上述したとおり、サーバーまたはネットワーク機器には管理ポートが装備されており、RS-232シリアル・ケーブルで接続されるシリアル端末（コンピューターが動作するターミナル・エミュレーション・ソフトウェア）により監視することができます。

コンソール・ポートが端末に直接接続されずCASに接続されている場合、システム管理者は非常にフレキシブルな方法でその管理インターフェイスを表示することができます。

コンソール・ポートにはネットワーク（LANから、またはインターネットにアクセスして）にアクセスできます。ネットワークがダウンしても、CASを使用しているとリモート・ダイアルアップ・アクセスから接続することができます。

通常、ユーザーはTELNETまたはSSHクライアントを使用してネットワークから特定のシリアル・ポートに接続します。CASには監視すべきシリアル・ポートに対応するための様々な方法があります。

• 設定で割り当てられたシリアル・ポートごとに個別のIPアドレスの使用。ユーザーはそのPIアドレスに対して単純にTELNETまたはSSHクライアントを使用し、シリアル・ポートに接続できます。これは数字のアドレス（DNSサーバー経由）よりも記号名を使用できるという利点と、複数のCASを1個の大型バーチャル・ボックスのように見せるという利点があります。この方法には別のIPアドレスをネットワークに割り当てる必要があるという潜在的な欠点があります。
• 設定で割り当てられたシリアル・ポートごとに個別のTCPアドレスの使用。ユーザーはCASに割り当てられた単一のIPアドレスへTELNETまたはSSHクライアントを使用し、（Telnetにより使用されるデフォルトのTCPポート番号の代わりに）を特別なTCPポート番号使用してシリアル・ポートを指定します。この方法ではIPアドレスを保存できますが、TCPポート番号の仕様をサポートするTelnet/SSHクライアントを使用する必要があります。
• TelnetまたはSSHを使用するCASへ接続し、メニューまたはコマンド・インターフェイスから手動でポートを選択。
• コンソール管理アプリケーション（Conserverなど）の使用。この場合、CASはシリアル・ポートへのソケット接続に対応する必要があります。この場合、アプリケーションには特定のユーザー・インターフェイスが装備されています。

TS1000およびTS2000製品は、ローカルまたはRADIUSデータベースのどちらを使用する場合でも、ポート・アドレス指定およびソケット認証のすべての方法に対応します。

ケーブル配線、ラックスペース、および物理的位置

CASはイーサネット・ハブまたはスイッチへの標準のケーブルを使用してLANに接続されます。

シリアル・ポートはRS-232クロスケーブルを使用してコンソールに接続されます。コンソールのボー・レートは通常低いため、シリアル・ケーブルは長くて数百フィートまでの長さになります。多くの場合、ケーブルはパッチ・パネルとラック・ケーブル管理システムを通ります。

TS1000またはTS200を基本としたソリューションの場合は、LAN接続は10BTまたは100BT（高速イーサネット）のいずれかになります。ユニットは高さ1U、電源が内蔵されている単一ボックスにすべて収容されます。ネットワーク・インターフェイスのほかは、外部ケーブルだけが電源コードで、CASは独自のコンソール・ポートを持っています。

Cyclades-Zを使用するサーバーベース・ソリューションの場合は、外部PC接続（電源、LANなど）のほかに、16ポートごとに1Uボックス1個があり、ボックスはSCSI-IIタイプのケーブルで相互に連結されます。

緊急リモート・ダイアルアップ接続ができるようにモデムも設置しようとしている場合は、このモデムはRS-232ストレートスルー・ケーブルからCASのRS-232ポートの一つに接続する必要があります。

クロスケーブルはデータ・ラインと制御信号を2つのポート（Rxに接続したTx、DTR－DCDおよびDSR、RTS－CTS）間を交差する2つのDTEデバイス（コンピューター、端末）に接続されます。ストレート・スルー・ケーブルはDTEデバイスをDCEデバイス（モデム）に1対1で接続します。このケーブルは1対1をベースにすべてのRS-232信号を接続します。

CASとコンソール・ポートの両サイドのRS-232シリアル・インターフェイスは、様々なコネクターに搭載されています。ケーブルはそれぞれに応じて設定する必要があります。

もっとも一般的なコネクターは RJ-45（TS1000、TS2000、Cyclades-Z、ほとんどのネットワーク機器、最新のサーバー）、DB-25（モデムと旧式の機器）、およびDB-9（ほとんどのサーバーとPC）です。DB-25とDB-9コネクターは標準のピン配列割り当てにしてあります。したがって、比較的簡単にプリメイド・ケーブルを製作したり、コンピューター・ショップから購入したりできます。

RJ-45はCASでより好まれるコネクター・タイプです。これは、このコネクターが小型で、データ・センターで使用されるパッチ・パネルと互換性があるからです。残念ながらRF-45コネクタにRS-232用の標準ピン配列が備わっていないので、各ベンダーは別のピン配列を使用します。

DB-25またはDB-9オス型コネクターを見ると、2列のピンがあります。左上のピンはピン1です。右下のピンはピン25（DB-25）またはピン9（DB-9）です。接続ピンが下向きのRS-45プラグを見ると、8個のピンが左から右に番号が付いています。

DB-25の標準ピン配列は、1-chassis、2-Tx、3-Rx、4-RTS、5-CTS、6-DSR、7-Gnd、8-DCD、20-DTRです。

DB-9の標準ピン配列は、1-DCD、2-RxD、3-TxD、4-DTR、5-Gnd、6-DSR、7-RTS、8-CTSです。

Cyclades RJ-45ピン配列（標準ピン配列なし）は1-RTS、2-DTR、3-TxD、4-Gnd、5-CTS、6-RxD、7-DCD、8-DSRです。

具体的なコンソール・アクセス・アプリケーション用のケーブル配線図を含め、ケーブル配線に関する詳細は、技術サポートおよび Cyclades社のWebサイトのTechtalkセッションを参照してください。

セキュリティと接続性

- サーバーとルーターのコンソール・ポートへのアクセス権を取得するユーザーは、潜在的にネットワーク全体を制御できます。CASには接続機能がすべて必要です。この機能を使用してシステム管理者はLAN、ダイアル接続またはインターネットからコンソール・ポートにアクセスできます。ただし、侵入者を防ぐためのセキュリティ機能も必要です。

パケットとサービス・フィルタリングネットワーク機能の一つ（古いCAS設計にはなかったことが多い）で、この機能を使用してシステム管理者はアクセス・ポリシーを設定したり、ソース・アドレス、送信先アドレス、ポート番号、プロトコル・タイプ、その他のパラメーターに基づいて選択的に接続を許可または拒否できます。

ソケット認証コンソール・ポートにアクセスしようとするユーザーの権限を検証するために重要です。認証にはパスワードが必要で、ローカル・データベースまたはRADIUSサーバーに対して確認できます。一部のターミナル・サーバーは、シリアル－ネットワーク間アクセスではRADIUS認証をサポートしますが、ネットワーク－シリアル間アクセスでは認証のサポートがありません。

Secure Shell (SSH). 通常のTelnet接続では、セッション画面とキーストローク（認証プロセスを含む）はクリア・テキスト・フォームでネットワークを移動します。データのトランジットが中断されるリスクがある場合（インターネット上での例）、ユーザーはSSHを優先しなければなりません。SSHはデータがネットワークで送信される前に暗号化します。

ダイアルアップ・セキュリティ. CASがダイアルアップ接続からリモートでアクセスされる場合、上述と同じセキュリティ機能がダイアルアップ回線でサポートされる必要があります。また、PAPおよびCHAPなどの別のダイアルアップ関連のセキュリティ・プロトコルもサポートされます。

すべてのセキュリティ機能がどの設定でも必要なわけではありません。CASの設定時、CASが機能するだけでなく、必ずお使いの環境のプロファイルを考慮してください。

TS1000/TS2000製品は、上述のすべての機能にサポートし、優れたレベルのセキュリティを提供します。Cyclades-Zに基づくサーバーベース・ソリューションの場合、OSは均等に安全になるよう正しく設定される必要があります。

ブレイク信号の送信

一部のサーバー（Sun/Solarisなど）はコンソール・ポートに「ブレイク」信号を受信するとモニターに切り替わります。この便利な機能を使用すると、システム管理者はシステムがロックアップしたときにサーバーをリセット/再起動/再設定を実行できます。

ブレイクとは

1本のRS-232ラインには"0"（-12V）および"1"（+12V）という2つのステータスがあります。「ブレイク」信号の送信は、ラインが1文字時間（通常数百ミリ秒）以上「1」のステータスにあることを意味します。

「ブレイクの問題」とは

今便利な機能の潜在的に好ましくない副作用と言えものは、偽のブレイク信号をシリアル・ラインに生成してサーバーの動作を意図せず停止してしまう可能性があることです。これはブレイク信号を使用してモニター・モードに切り替えるサーバーにのみ影響します。

システムの電源がオフになっていると、シリアル・ラインのステータスを制御できません。ケーブルとシリアル・ポートで構成されている回路の電気的特性に応じて、シリアル・ラインに電圧フリッカが生じ、反対側に「ブレイク」として解釈される場合があります。

その結果は、条件が正しい（または不適切な条件）場合、CASの電源を切って直ちに入れ直すとサーバーをCASに接続してコンソール・ポートで「ブレイク」信号が見えるようになります。CASが意図的にブレイク信号を送信しないことに気づいてください。ただし、コンソール・ポートはランダムな電気変動の結果としてブレイク信号を表示します。

この現象はCASへの外部要因の影響を受けるので、お使いの環境では生じないと絶対に保証することはできません。ただし、ボックスの電気設計はブレイクの問題を必然または非常にまれなイベントにすることができます。

TS1000/TS2000とCyclades-Z製品は、低ノイズ回線ドライバを使用し、シリアル・インターフェイスは特にこの問題の発生を防止するために設計されています。さらに、TS1000/TS2000は特殊な電源回路を持ち、電源のオン／オフ中のランダムな電源変動を防止し、意図的でないブレイク信号の可能性を実質的になくします。

この問題を回避する最善の方法とは

現在のSunサーバー（1999年11月以降にリリースされたSolaris OSまたはSunのサポートサイトで取得可能なパッチ107589-03を手当てした旧バージョン。）を使用しており、意図的でないブレイクが生じる傾向を持つCASを使用している場合、問題は設定により回避できます。ファイル（/etc/default/kbd）を編集してASCII文字の特定の文字列（偶然生成されたと思われないもの）を選択し、「モニター・モードに切り替える」か、単純に機能を無効にします。

ソフトウェアにより問題を回避できない場合

サーバーのブレイク機能でリセットを無効にできないまたはしたくない場合でお使いのCASと環境で問題生じたときは、解決策としてCASをブレイク・セーフ製品と差し替えることが考えられます。その前に、お客様が繰り返し使用してある程度成功している別の解決策を試すことができます（ただし、Cycladesではテストを行っていません）。

• ケーブルの設定を変更または廉価な「RS-232 light-boxes」を回路内に挿入して回路の電気特性を変更します。
• 「プルダウン」レジスタ（4.7K Ohm）をRxラインとGnd（コンソール・ポート側）間に挿入して、CASの電源がオフになったときの電圧フリッカを防止します。レジスタはRJ-45ケーブル・システムのRJ-45－DB-25アダプタ内簡単に取り付けることができます。

ブレイク信号を送信する場合は、Telnetエクステンション（RFC 2217、854で説明）にサポートするCASが必要です。この場合、必ずTelnetクライアントがTelnetエクステンションを使用してブレイク信号を送信できなければなりません。

TS1000/TS2000 CASは意図的でないブレイク信号の生成を許可せず、RFC 2217コマンドから意図的にブレイク信号を送ることができます。

上述のように、Sunサーバーをモニター・モードにリモートで切り替えることができる場合、/etc/kbdの編集を行って、偶然に生成されず意図的に生成しやすいと思われる特定のASCII文字列を選択することを推奨します。

本書に含まれる情報は、当社独自の経験を記載していますが、多くのCycladesのお客様にご協力いただいております（多数のため掲載できません）。本書を使用した後に、他のユーザーの方に役く立つと思われる情報がありましたら、是非お知らせください。

本サイトに収録の全文書の所有権は、Cyclades Corporationに属し、Cyclades Corporationからの書面による同意なしで、複製または再出版することはできません。