エージェントレス・サーバの管理容易性が大幅に向上

ITマネージャは、ソフトウェアまたはオペレーティングシステムのレベルでのサーバ管理を行うための選択肢の多さに慣れ切っている。一般的に言って、これらのアプリケーションは購入および運用の費用がかさむため、あらゆる運用シナリオに対応させることはできない。また、管理システム全体の内部での統合性が十分でないことも予算の圧迫につながる。こうしたギャップを埋めるため、業界の各組織は何らかの助けとなり得るオープンな管理の標準を定めている。実際、ベンダはこれらの標準規格を、サーバ全体の一部となる事前統合された管理機能として実装することに余念がない。この事前統合のアプローチはエージェントレスと呼ばれることがあり、既存のエージェントベースの管理方式を補完するものである。多くのベンダが提供するサーバ関連製品の中で現在、利用可能になりつつある次世代のエージェントレス・テクノロジは、膨大な数にのぼる。

OSベースのエージェントは広く一般に理解されており、サーバの可用性の改善に役立っている。ただし、これらのソフトウェアエージェントはシステムの可用性に依存しており、OSが存在して正常に動作している必要がある。OSにアクセスできなければ、エージェントは動作できず、コンソールにレポートすべき統計情報を取得できない。ハードウェア管理の面では、ベンダによって管理機能がサーバ内に組み込まれたものの、多くの場合はマシン内外に相互運用性がほとんどない、またはまったくない独自仕様のコンポーネント(Hewlett-PackardのiLOなど)が使われた。スクリプトは日常的なタスクを自動化するなどいくらか役立っているが、同じ処理(サーバの電源投入など)の実行にベンダ間で異なったコマンドおよびインタフェースが使われている。このことは、スクリプト処理を複雑にしている。というのも、ITマネージャはサーバの種類ごとに別のスクリプトを学び、完成させ、メンテナンスする必要があるからだ。このように、OSのすべての状況に対応する方法が存在せず、ハードウェア管理に対する標準化が行われていない状態で、ITマネージャはマルチベンダ・ネットワークの管理に必死に取り組んでいる。

IPMI標準規格

Intelligent Platform Management Interface(IPMI)は数年前にDell、HP、Intel、NECが着手した標準規格であり、システムのハードウェア管理のインタフェースおよびプロセスが標準化されている。最新改訂版のIPMI v2.0では、以前のバージョン1.5に新しい機能が追加されている。最も注目すべきは、認証(SHA-1およびHMACベースのもの)および暗号化(AESおよびRC-4)の強化、ブレードおよびVLANのサポート、(テキスト)コンソールへのアクセスの標準化である。IPMIは、世界中の180を超えるベンダが自社製品の一部として採用しており、過去数年間で300万台を超えるサーバに含まれている。2005年に出荷されたサーバの50%以上には、IPMIが事前に組み込まれていた。

IPMIは、ITマネージャがシステムのハードウェアやセンサ(温度、電圧、ファンなど)の監視、システムコンポーネント(電源、ブレードなど)の制御、重要なシステムイベント(筐体の開閉、システムのリセットなど)のログ記録、管理者による故障システムの遠隔管理やリカバリの許可を行えるように、ベンダに設定させるための共通かつセキュリティ上安全なインタフェースを定義している。

IPMIの基礎となる部分は、サービスプロセッサやベースボード管理コントローラと呼ばれることもある専用チップおよびコントローラ上で実行される特殊なファームウェア内にある。このサブシステムはベンダ、またはCPUやOSの状態に関係なく動作し、システムのそれ以外の部分が使用できないときでも監視やリカバリが可能である。したがって管理者は、たとえサーバのOSが読み込まれていなかったり、不安定になっていたり、または反応しない場合にも、IPMIの情報にアクセスできる。

IPMIの大きな強みは、その遠隔管理機能にある。たとえば、システムのテキストコンソールへのリモートアクセスが必要な場合は、Serial Over LAN(SOL)の機能がとても役に立つ。SOLはローカルサーバのシリアルインタフェースやポートをIPMIセッションを介してリダイレクトし、WindowsのEMS SAC(Emergency Management Services Special Administration Console)やLinuxのシリアルコンソールへのリモートアクセスを可能にする。この機能は、サーバに関する問題の診断と修復をベンダとは無関係に行うために、ブート、OSローダ、緊急管理の各コンソールをリモート表示させる標準的な方法として使われている。また、ブートフェーズ中にさまざまなコンポーネントを設定することも可能である。多くの場合、リモート管理者はこれらの処理を対話的に行うことで、サーバマシンに赴くことなく設定の調整や追加の診断を進めることができる。集中配置されたコンソールや、通常はサーバベンダによって提供されるか既存の管理アプリケーション内部の機能として用意されている管理ユーティリティ(Dell PowerEdgeサーバにバンドルされているAvocentのソフトウェアユーティリティIPMISHや、LANDesk Server Managerなど)を使って、管理者はサーバの運用状態を確認できる。IPMIが利用可能なこれらのアプリケーションは、リモート管理者が曜日を問わず24時間いつでもイベントログやセンサ情報を確認できるようにIPMIファームウェアと直接通信を行う。

SMASH標準規格

緊急または特別な状況では、多くの場合、管理者は特定のコマンドを使って各種サーバを対話的に管理する必要がある。そのとき問題になるのが、同じことをするにもベンダが違うとコマンドまで異なるという点である。ここでSMASHについて説明しよう。Distributed Management Task Force(DMTF)によって定義されたSystems Management Architecture for Server Hardware(SMASH)のワーキンググループは今年前半に、こうしたコマンドラインの一貫性の欠如を解決する最初の仕様SMASH Command Line Protocol(CLP)を公開した。

SMASHに対応したサーバの場合、管理者はTelnetやSSHといった汎用のソフトウェアクライアントを使って対話セッションを開くことでアクセス権が得られる。管理者は、管理可能なシステムリソースの一覧を表示するSMASHのSHOWコマンドによってSMASHの利用を開始できる。その後はSMASHのSTARTおよびSTOPコマンドにより、電源、ファンを始めとするサーバ内部にあるこれらのリソース(またはSMASHで言うところの管理対象要素)を制御できる。

IPMIとSMASHを互いに協調し合うものとして検討することも有益である。たとえIPMIが標準化されたメッセージ・インタフェースを開発者やベンダのために提供していても、実際のサーバのコマンドライン・インタフェースはベンダ間で異なっているのが普通である。そこでSMASHがそのままの状態で利用可能な基本のコマンドライン・インタフェースになり、IPMIのハードウェア健全性管理機能にアクセスを行う。

複数のIPMIサーバのサポートに関心があるか多数のサーバ間で管理責任を分担したいと考えていて、SMASHインタフェースを用いることの重要性がわかっているIT機器の管理者では、Avocent MergePoint 5200のような専用の管理機器の使用を検討するとよい。ラック設置型専用機器を介したサーバへのアクセスを管理者に強制することによって、単独のコマンドセットを複数のサーバ間で使えるだけでなく、追加のセキュリティおよび制御機能を提供することができる。

IPMI v2.0準拠のサーバとSMASHベースのゲートウェイ機器はすでに出荷されているため、ITマネージャが運用コストの管理および削減のためにエージェントレス機能を利用する方法を策定し、それによってラック内サーバの信頼性と可用性を向上させるには、今がちょうどよい時期である。

Steve Rokov氏はAvocentのテクニカル・マーケティング・ディレクタを務め、エージェントレス管理の標準規格およびテクノロジをユーザ、ベンダ、業界の権威者の間に普及させる活動の責任者である。また、DMTFやIPMIフォーラムなど、ネットワークの管理容易性に関する各種業界団体にも加わって積極的に活動している。

NewsForge.com 原文