Yahoo! JAPAN での IPMI 活用事例

サイトオペレーション本部の渡邉です。
サイトオペレーション本部はデータセンター・ネットワーク・サーバー・OS・ストレージ・OpenStack などの全社的な基盤インフラの管理運用や調査検証などを担当しています。今回は Yahoo! JAPAN のサーバー運用を裏から支えている IPMI の仕組みと、その運用システムや OCP サーバーでのケーススタディーについて紹介します。

IPMI とは

IPMI: Intelligent Platform Management Interface は、サーバーを始めとするインフラ機器で広く採用されている管理インターフェースの規格です。1990年台に Intel が提唱を始めた規格で、最近のサーバーであれば基本的に対応していると考えて良いでしょう。

IPMI に対応しているサーバーは一般的にサービスポートに加えて専用のマネジメントポートを備えており、ここに LAN ケーブルをつないで IP アドレスを割り当てることで、便利な機能をリモートから実行できるようになっています。

実運用でよく使われるのは次のような機能です。

• 電源のオンオフ
• シリアルコンソールの操作
• ブートデバイスの変更
• 筐体に搭載された各種センサー値の取得
• ハードウェアレベルのエラーログ取得

IPMI の機能はサーバーにインストールされた OS とは完全に独立して動作します。そのため、たとえ OS がハングアップしてしまった時でも操作を実行できます。

IPMI の内部構成

IPMI は BMC: Baseboard Management Controller と呼ばれる管理用の SoC: System on a Chip を中核に実装されています。BMC はマザーボード上に搭載されている小さなサーバーのような存在で、リクエストを受け付けて筐体に搭載されている様々な回路や部品に指示をだすことで、管理機能を提供します。

次の図は BMC の周辺を簡略的に示したものです。

BMC にはセンサーや電源制御のための回路のほかに不揮発性ストレージが接続されており、SEL / SDR / FRU の情報を保存しています。

SEL は System Event Log の略称です。System Event とは筐体におきたハードウェア的な事象全般を指します。例えば電源のオン・オフや CPU の温度異常などの事象は全て System Event として SEL に記録されています。記録内容は基本的に指示があるまで消去されることはなく、容量の上限に達した場合は古いログを保持します。これには、最初に起きた事象が最も根本原因に近いものであるという考え方が背景にあるためです。

SDR は Sensor Data Record の略称で、筐体に実装されている各センサーそれぞれについて読み取れる情報やその閾値などを定義するものです。たとえば、この配線に接続されている汎用センサーは CPU0 の温度を出力するもので、90度を超えたら異常であるといった定義がなされています。また SDR には Entity Association Record と呼ばれる特殊定義があり、複数のセンサーを束ねて1つのセンサーとみなすことができます。たとえば複数の電源ユニットそれぞれの電流センサーを束ねて、冗長化電源の電流センサーとして定義できます。これにより「電源の冗長性ロスト」といった System Event を表現することができます。

FRU は Field Replaceable Unit の略称で、一般的にその筐体のモデル番号やシリアル番号を定義するものとして使われています。

また、BMC は IPMB: Intelligent Platform Management Bus という I2C ベースのバスを持っており、ここに Satellite Controller と呼ばれる追加のコントローラチップを接続して機能を拡張することも可能です。

BMC との通信

BMC にリクエストを送る際は、主に次の2つの経路が利用されます。

• RMCP+ over UDP/IP
• システムバス

前者はマネジメントポート経由でリモートから操作する out-of-band の経路です。IPMI のコマンドを RMCP+: Remote Management Control Protocol+ で包んで UDP/IP にのせて通信します。RMCP+ はシンプルな request-response で通信するプロトコルです。

後者は OS のドライバーから操作する in-band の経路です。Linux であれば IPMI デバイスから一般的に KCS: Keyboard Controller Style で指示を出します。KCS は Intel が 8742 Universal Peripheral Interface microcontroller という 8-bit マイコン向けに開発した制御規格で、現在でも一般的に使われているものです。

IPMI 運用システム

Yahoo! JAPAN では IPMI を活用するためのシステム tsuna を内製で開発して運用しています。10万台を超える台数になってくると BMC に割り当てる IP アドレスの管理が課題となってきますし、IPMI の提供する非常に強力な機能の権限管理が必要だからです。たとえば、自分が運用しているサーバーの電源をリセットするつもりだったのに、間違えて全く関係のないサーバーに対して実行してしまったとなったら大変です。あるいは悪意のある侵入者が全てのサーバーの電源をオフにしてしまうといった可能性も考慮しなければなりません。

この tsuna の具体的な構成について物理的な面から順を追って説明していきます。

次の図は Yahoo! JAPAN のデータセンターのラックにおける一般的な機材配置を示したものです。サービス用のエッジスイッチに加えて IPMI エッジスイッチが置かれており、サーバーのマネジメントポートは全てこちらに配線されています。ラックにはオーナーの異なる様々なサーバーが置かれていますが、IPMI エッジスイッチは特にこれを区別することはせず L2 フラットで構成しています。権限分離はソフトウェアのレイヤで担保してスイッチの運用をシンプルにしています。

これらラックごとの IPMI エッジスイッチは、ラック列ごとに設置された列アグリゲーションスイッチに接続されます。そして、列アグリゲーションスイッチは更にフロアごとに設置されたフロアアグリゲーションスイッチに接続され、最終的にクローズドな L2 フラットネットワークが構成されます。

tsuna はこの IPMI ネットワークごとに設置されており、通常のネットワークと IPMI ネットワークに対してインターフェースを持つように構成されています。tsuna が担うのは次のような機能です。

• IPMI ネットワークへのインターフェースの提供とそれに対する権限制御
• BMC への DHCP による IP アドレス自動割当管理
• BMC のセキュリティー設定投入
• BMC の死活監視
• BMC からの SEL 取得と分析
• BMC からのセンサー情報収集

各フロアにいる tsuna は中央データベースで BMC の状態などを管理しつつ、メッセージキューを通じて様々なリクエストに応答します。

IPMI as a Service

サーバー担当者は専用の踏み台から IPMI の機能を利用することができます。この踏み台はログインシェルが rbash に制限されています。また poweron や poweroff といった IPMI の機能単位で用意されているコマンドのみが実行可能になっています。そしてこれらのコマンドは次のような流れで処理を進めます。

• 対象に対してユーザーが権限を持っていることを確認
• 対象が死活監視で問題ないことを確認
• 対象がどの tsuna に管理されているかを確認
• リクエストを対象の tsuna に転送
  • tsuna 側は権限をダブルチェックして実行

OCP サーバーでの IPMI 活用事例

ここまでで、IPMI の概要や Yahoo! JAPAN での IPMI 運用環境についてご理解いただけたかとおもいます。最後に IPMI を活用して OCP サーバーの運用を効率化している事例について紹介します。

OCP: Open Compute Project は Facebook が提唱を始めたプロジェクトで、データセンターに関わる様々なハードウェアの設計をオープンソースにしていこうという取り組みです。サーバーやネットワークをはじめとして各種領域で活動が進められており、Yahoo! JAPAN でも導入が進んでいます。

OCP サーバーは自分たちに最適な構成を組み上げてコストを削減するなどの施策を取りやすい反面、メーカーによる手厚いサポートはありません。たとえば筐体のハードウェア不良が疑われるとき、メーカー製のサーバーであれば SEL を確認して異常らしきログがあれば、あとはセンドバックして細かい切り分けや交換をメーカーにまかせるといった運用ができますが、OCP サーバーの場合は自分たちで原因を切り分けて、パーツ交換を手配する必要があります。

このために私たちは IPMI の SEL を活用しています。

次のログは実際にハードウェア障害が起きてハングアップしてしまった OCP サーバーの System Event リストの抜粋です。16:43:29 に修正可能な ECC エラーが発生したあと、たてつづけに Unknown エラーが発生していることが見て取れます。なんとなくメモリーが怪しそうですが、これだけではまだ被疑箇所を特定することができません。

  ee | 12/05/2017 | 16:43:29 | Memory #0x9f | Correctable ECC | Asserted
  ef | 12/05/2017 | 16:43:52 | Unknown #0x63 |  | Asserted
  f0 | 12/05/2017 | 16:43:55 | Unknown #0x63 |  | Asserted
  f1 | 12/05/2017 | 16:44:12 | Unknown #0x63 |  | Asserted
  f2 | 12/05/2017 | 16:44:24 | Unknown #0x63 |  | Asserted
  f3 | 12/05/2017 | 16:44:27 | Unknown #0x63 |  | Asserted
  f4 | 12/05/2017 | 16:44:39 | Unknown #0x63 |  | Asserted
  f5 | 12/05/2017 | 16:44:47 | Unknown #0x63 |  | Asserted
  f6 | 12/05/2017 | 16:44:58 | Unknown #0x63 |  | Asserted
  f7 | 12/05/2017 | 16:45:04 | Unknown #0x63 |  | Asserted

手がかりになりそうな System Event の見当を付けたら、詳細を掘り下げていきます。ここでは最後に発生したものを見ていきます。

SEL Record ID          : 00f7
 Record Type           : 02
 Timestamp             : 12/05/2017 16:45:04
 Generator ID          : 0001
 EvM Revision          : 04
 Sensor Type           : Unknown
 Sensor Number         : 63
 Event Type            : Sensor-specific Discrete
 Event Direction       : Assertion Event
 Event Data            : a50030
 Description           :

この中で重要なのが Sensor Number (63) と Event Data (a50030) です。OCP サーバーは公開された仕様に基いて製造されており、Event Data を Sensor Number ごとのルールにのっとって詳細に読み解くことができるからです。逆にメーカー製のサーバーでは、こういった仕様は各社で統一されておらず仕様も原則非公開のため、メーカーに頼らざるを得ません。

Event Data は 24bit で表現されており、これをオクテット単位に分割して解釈します。次の図は OCP の仕様書の抜粋です。

Sensor Number 63 は Memory ECC Error を示すものであることや、オクテット毎にビットパターンをどう解釈すべきかが記載されています。これにそって解釈をすすめると、次のような結果を得ることができます。

CPU1 の DIMM0 に挿入されているメモリーモジュールが大量の ECC エラーを発生させており警告閾値に達しているということがわかりました。

ここまでの流れでは仕様書を眺めながら解釈を進めましたが、実運用でも手動でやるのは苦行です。そこで、OCP サーバーの導入にあわせて tsuna にはリモートからこの処理を自動で行うための機能が実装されています。Web API にリクエストを送るとリアルタイムに SEL の取得とパースが実行され、次のように JSON で結果が帰ってくる仕掛けです。これにより、Yahoo! JAPAN では OCP サーバーの障害原因を速やかに切り分けて復旧対応を行うことができています。

  {
    "sensor_name": "name: Memory ECC Error",
    "event_data1": "ed1 a5(10100101): Correctable ECC error Logging Limit Reached = 5(0101:0-3)",
    "event_data2": "ed2 00(00000000): All info available = 0(00:2-3), logical rank = 0(00:0-1)",
    "event_data3": "ed3 30(00110000): CPU Number = 1(001:5-7), Channel Number = 2(10:3-4), DIMM Number = 0(000:0-2)",
    "timestamp": "12/05/2017 16:45:04"
  }

IPMI はそれなりに歴史が長いので、慣れた人からするとあまり新鮮味のない技術であると思います。しかし OCP サーバーのように仕様が公開されたサーバーが出てくると、この事例のように更に運用を効率化するための道具として再び活躍の場が広がっていくのではないかと感じています。

おわりに

簡単ではありますが、Yahoo! JAPAN での IPMI の活用について OCP サーバーでのケーススタディーを交えながら述べさせていただきました。

本稿のような領域に限らず、サイトオペレーション本部はさまざまなインフラ領域で日々チャレンジを続けています。ご興味のある方がいらっしゃいましたら、ぜひ採用サイトもご覧ください。

最後までお読み頂きありがとうございました。