サービス・プロセッサー管理
特長
サービス・プロセッサーの機能はタイプによって異なる
全サービス・プロセッサーに共通の機能もあります。リモートでの電源操作機能(電源投入、電源停止、オフ/オンのリセット、電源ステータス)とSerial over LAN(SoL)を介したリモート・コンソールへのアクセスはすべてのサービス・プロセッサーが提供する機能です。サービス・プロセッサーのタイプによっては、サーバーの作動状態のモニタリング(ファン速度と状態、温度、電圧)、OSレベルでのグレースフル・シャットダウン機能、リモートでのキーボード/ビデオ/マウス(KVM)機能、およびバーチャル・メディア機能などのより高度な機能を提供できるものもあります。これらの機能を以下に詳述します。
- リモートでの電源管理 – サービス・プロセッサーを介して、リモートでサーバー電源を停止、投入、リセットすることができます。これはサービス・プロセッサーの機能のうち最も便利なものの1つです。リモートでの電源制御は、不良状態のサーバーの復元、過熱したサーバーの停止、またサーバーとの低レベルの交信を要するその他の機能に対して使用されます。
- グレースフル・シャットダウン対応– 一部のサービス・プロセッサーでは、サーバーの電源をリセット/停止する前にサーバーのOSを正常のプロセスでシャットダウンさせる(グレースフル・シャットダウン)コマンドが実際に送信されます。これにより、強制終了や強制的な電源リセットによって起こるサーバー・ハードドライブのデータ破壊などの望ましくない影響を回避できます。
- SoLコンソールへのリモート・アクセス– サーバー・コンソールへは、サービス・プロセッサーのイーサネット・インターフェイスを介し、標準のTelnetまたはSSHクライアントを使用して、通常のシリアル・ポートを介するのと同じようにアクセスします。サーバーがBIOSのシリアル・ポートへの出力先変更をサポートしていれば(サービス・プロセッサーを備えたサーバーでは大抵サポートされています)ユーザーはサーバー・コンソールへの完全アクセス(起動時点からBIOSプロセスを通してOSのログイン・プロンプトまでに及ぶ)を得ることができます。これはリモートでトラブルシューティングを行う上で非常に便利です。
- 作動状態のモニタリング– サービス・プロセッサーはサーバー内の該当のセンサー・ハードウェア(ファン速度モニター、電圧計、温度センサーなど)と交信してサーバーの重要値にアクセス/モニターし、サーバー障害の迅速な検出を図っています。サーバーの作動状態の情報は、サーバーに保存するか、リモートの記憶装置に送信する、またはユーザー・ワークステーションに直接送信することができます。
- ID LEDのリモート制御 – 管理者はサービス・プロセッサーによりサーバーのID LEDをオンまたはオフにすることができるようになります。これにより、同様のサーバーが複数配置されたラック内で特定のサーバーをマークし識別できます。これは、サーバーがメンテナンスを要するものの現地の技術スタッフが該当のサーバーの情報を把握していない場合に特に有用です。この場合、管理者は当該サーバーのID LEDをオンにすることで、どのサーバーのメンテナンスが必要なのかを現地スタッフに知らせることができます。
- ローカルおよびサーバーベースの認証– サービス・プロセッサーの機能にアクセスするにはまずログインしなければなりません。ユーザー・データベースは通常の場合サービス・プロセッサーにローカル保存されています。また一部のサービス・プロセッサーでは、LDAPやActive Directoryのような中央認証サーバー機構との交信も可能になっています。
- データの暗号化– 暗号化を許可する通信プロトコル(Secure Shell (SSH) またはSecure Socket Layer (SSL) など)をサービス・プロセッサーがサポートしていれば、サービス・プロセッサーとユーザー間の通信は暗号化できます。最新のサービス・プロセッサーは何らかのレベルのデータ暗号化に対応しています。
- システム・イベント・ログ(SEL)– サービス・プロセッサーはサーバー・ハードウェア関連のイベント情報(シャーシの開閉、ハードドライブ機能関連のアラーム、RAMテスト・エラーなど)を保存できます。これらのイベント・ログ情報は、この後管理者による直接確認または自動アラートのトリガーとして使用されます。
- プラットフォーム・イベント・トラップ(PET)– サーバー環境変数(作動最大温度、CPUファンの最低速度など)の重要閾値を入力してサービス・プロセッサーをプログラムすることができます。この後は各閾値に基づいて管理システムにアラート(トラップ)が送信されます。サーバー管理者が該当の障害に即座に対処できるよう、通常これはSNMP形式で送信されます。
- データ・ログ– 一部のサービス・プロセッサーは、セッションへの接続ユーザーの有無に関わらず、サーバーのシリアル・コンソールを通してデータ・フローをログする機能を備えています。このため管理者は、変更履歴やトラブルシューティングの際に有用な監査証跡を参照し、特定のイベントが発生する前のイベント履歴を確認できます。
- バーチャルKVM– これはSoL機能に似ていますが、サーバーのテキストベースのシリアル・コンソールへのアクセスをユーザーに与える代わりに、バーチャルKVMではサーバーのGUIへのアクセスが提供されます。これは、WindowsのようにGUIに大幅に依存するオペレーティング・システムでは特に重要となります。
- バーチャル・メディア– 一部のサービス・プロセッサーでは、記憶媒体(CD-ROM、フロッピー・ディスク、DVD-ROMなど)にネットワークのどこからでも(あたかもサーバーに直接接続されているかのように)アクセスできるようになっています。ユーザーはこれにより、ユーザー・ワークステーションからサーバー(この逆方向でも)にデータを容易に移動/コピーすることができます。これはOSやアプリケーションのパッチを緊急にインストールする場合、また診断テストやBIOSアップグレードなどの場合に便利です。バーチャル・メディアおよびバーチャルKVMでは、ユーザーが毎日すでに使っているインターフェイスとツールを用いた真の完全自動管理が可能になります。
メリット
サービス・プロセッサーの機能の多くは他のリモート管理ソリューション(コンソール・サーバー、KVMスイッチ、IPDUなど)を通しても何らかの形で得られるもので、新しくはありません。では、サービス・プロセッサーからはどんな新しいメリットが得られるのでしょうか?
リモートの帯域外管理ツールから得られるメリットのすべて(平均復旧時間 (MTTR) の短縮、運用コストの削減、資産生産力の向上)は、サービス・プロセッサーを通しても得られます。ただしサービス・プロセッサーの場合、これらのメリットを得る上での機能が全て、サーバーに既に含まれている点が相違点となっています。さらに唯一のインターフェイスは、IT分野内に最も広く存在するイーサネットです。このためリモート・サーバー管理インフラの導入が簡素化され、IT管理部門はこの技術をより容易に利用することができます。またサービス・プロセッサーがサーバーに組み込まれていることでサーバー状態をより綿密かつ精密にモニターでき、先を見越した予防管理を実行しサーバー・インフラ全体をより上手に管理することができます。ハードウェア環境のモニタリングやプラットフォーム・イベント・トラップなどは、サービス・プロセッサーがサーバー内に存在することから直接得られる機能です。
課題
IT業界の昨今の動向により、リモートでの完全自動管理への需要が著しく高まっています。 データ・センターの統合、施設コストや外注の削減の必要が迫られる場合、しばしばデータ・センターを管理する要員から引き離す結果となります。また温度や騒音その他の環境の条件によりデータ・センターにスタッフを配置できない場合もあります。
加えて、過去3年間に購入されたサーバーの大部分には何らかのサービス・プロセッサーが組み込まれているので、サービス・プロセッサーは実はIT環境にすでに広く存在しています。主要サーバー・メーカー(Dell、HP、IBM、Sun)によれば、2005年末までに業界内で使用されていたサービス・プロセッサー付きサーバーの台数は約900万台にのぼっています。リモートでのサーバー管理に必要なサービス・プロセッサーはすでに購入/清算済みであることも考慮すると、これは需要と供給の理想的な組み合わせでしょう。
しかしながらサービス・プロセッサーの使用/導入は実際には思わしくありません。サービス・プロセッサーからは多くのメリットを得られるにもかかわらず、IT管理者たちはサービス・プロセッサーのイーサネット・ポートを未使用または無効のままにしており、求めているソリューションそのものが身近にあるのに利用していないのが現状です。上述の主要サーバー・メーカーは、2005年末までの業界でのサービス・プロセッサー使用は140万件にとどまっていたと報告しています。
サービス・プロセッサーが主流として採用されることを阻む要因はいくつかあります。サーバー・ベンダーは IPMI のような標準のサービス・プロセッサー・インターフェイスに固執することに乗り気ではありません。これはサービス・プロセッサーのいわゆる「限界」のためです。実際、大部分のサーバー・ベンダーが各自のプラットフォームに IPMI を含めてはいるものの、専有のサービス・プロセッサー・ファームウェア・エクステンションや管理ソリューション・パッケージ下でなければ使用できないようになっています。これらのベンダー特有の機能は当該ベンダーのサーバーしかサポートしておらず、他社製の製品とは互換性がありません。
これに加えて、サービス・プロセッサーの持つ潜在能力については多くの企業がまったく気付いていないか、意識していても既存の管理フレームワークに統合する際の懸念から使用を躊躇しているのが現状です。さらに、互換性やコストの問題、中央集中管理の欠如が難点となっている場合や、セキュリティと機能性の面で踏み切れないでいる場合などもあります。
導入への課題
- サービス・プロセッサーはサーバーごとに別個のイーサネット接続とIPアドレスを必要とするため、追加のコストが発生します。このコストには追加のイーサネット・スイッチ・ポートのコストだけでなくこの接続を企業方針に準じて保守するコストも含まれますが、これは専用のイーサネット・ポートを要するサービス・プロセッサーの場合のみです。
- 適切な認証/承認/アカウント管理(Authentication, Authorization and Accounting: AAA)セキュリティ・サポートがサービス・プロセッサーに組み込まれていない場合も、既存のセキュリティ機構や方針に統合・準拠させるのが困難になります。HP社の iLO はこの場合の例外となっています。
- IPMI は側波帯のケースでは特に、セキュリティ面の懸念が理由でサーバー内で無効になっています。サーバーで IPMI を有効にしたい場合、管理者は、サーバーのBIOSにアクセスするか、あるいは適切なBIOS構成コマンドを含むOSイメージでサーバーをPXE起動する必要があります。多くのサーバーが既に稼動している大型の企業環境の場合、これは特に難しいタスクです。
- 企業内にすでに存在しているサービス・プロセッサーを検出できない場合も、企業のIT環境でサービス・プロセッサーからのメリットを即座に受けられないことにつながります。
- 複数のサーバー用の統合ツールは特定ベンダーにしか対応していないか機能性に欠ける場合があり、サービス・プロセッサーの活用に互換性と拡張面での問題を残します。
- このように、既存の管理フレームワークへのサービス・プロセッサー管理の統合は、規格の欠如とベンダー特定のツールによる限界が理由で困難になっています。また、サービス・プロセッサーは、コンソール・サーバーやKVMスイッチのような既存のリモート・サーバー管理ツールに対しては統合ができなくなっています。
|