ストーリーを完了するには、遠くから少し始めて、サービスプロセッサの目的と、サーバーの動作におけるBMCの役割、IPMIプロトコルとソフトウェア部分に影響を与えることについて話さなければなりません。 その後、BMCがPOWER8でのシステムのブートにどのように関与するかを簡単に説明します。 最後に、OpenBMCプロジェクトの概要と問題に対する私たちの態度について説明します。 サービスプロセッサのテーマを経験した読者は、すぐに下位セクションに巻き戻すことができます。
サービスプロセッサ-何、なぜ、どのように
サービスプロセッサは、サーバーに組み込まれている別個の専用コントローラーです。 そのチップは、マザーボードにはんだ付けするか、別のカードに配置するか、たとえばブレードシャーシに配置して、システム全体のリソースを全体として管理できます（そして、すでにSMC-System Management Controllerと呼ばれています）。 BMCは、個別のホストを管理するためのサービスプロセッサの特殊なケースです。以下では、それらについてのみ説明し、「サービスプロセッサ」という用語は「BMC」の意味でのみ使用します。 同時に、「BMC」とは、一般的に、チップ自体と制御ファームウェアの両方を意味します。 場合によっては、ハードウェアまたはソフトウェアについて話していることを別に示します。
BMCはメインシステムとは別に電源が供給され、スタンバイ電源がサーバーに供給されると自動的にオンになり、電源がオフになるまで動作します。 ほとんどすべてのサービスプロセッサは、ホスト電源を管理し、シリアルオーバーLAN（SoL）を介してメインオペレーティングシステムのコンソールへのアクセスを提供し、システムセンサー（ファン速度、電源とVRMの電圧、コンポーネント温度）を読み取り、コンポーネントのヘルスを監視し、ハードウェアを保存しますエラーログ（SEL）。 多くは、リモートKVM、仮想メディア（DVD、ISO）を提供し、さまざまな帯域外接続プロトコル（IPMI / RMCP、SSH、RedFish、RESTful、SMASH）などをサポートしています。
リモート制御が広く普及しています。 大規模なサーバー群の管理を容易にし、ダウンタイムの削減により可用性を向上させ、データセンターの運用効率を向上させます。 その結果、ハードウェアプラットフォームのサプライヤを選択する際に、広範なリモート管理機能の可用性が顧客によって考慮されます。
BMCユーザーは、主にリモート管理、クラッシュリカバリ、ログ収集、OSインストールなどのシステム管理者です。 テクニカルサポートは、サービスプロセッサからのデータを使用します。 彼女にとって、多くの場合、BMCはトラブルシューティングと欠陥のある交換コンポーネントの特定における唯一の情報源です。
近代的なインフラストラクチャでは、BMCはリモートサーバー管理のための単なる追加のオプションではありません（ただし、寒くて騒がしく、座っている場所がなく、モバイルをうまくキャッチできないサーバールームには行きません）。 多くの場合、これはインフラストラクチャの重要なコンポーネントです。 オペレーティングシステムまたはアプリケーションが応答しないか、理解できない状態にある場合、サービスプロセッサが唯一の情報源であり、作業を迅速に復元する方法です。
サービスプロセッサに接続するには、専用ネットワークポート（帯域外）を使用するか、BMCがネットワークポートをメインシステム（サイドバンド）と共有します。 つまり、1つの物理イーサネットコネクタですが、2つの独立したMACと2つのIPアドレスです。 初期セットアップでは、RS-232コンソール接続がよく使用されます。
IPMI
クイックリファレンス
歴史的に、BMCソフトウェアはサーバーハードウェアプラットフォームと同じ開発者と共に開発されました。 その結果、サービスプロセッサソフトウェアはプラットフォームごとに一意でした。 同じベンダーが、さまざまな製品ライン用にいくつかのBMCファームウェアオプションを持つことができます。 オープンソースの普及にもかかわらず、長い間BMCファームウェアは独占的に独占されたままでした。
通常、サービスプロセッサは、チップ（System-on-Chip、SoC）上の特殊なシステムに基づいており、IPMI（Intelligent Platform Management Interface）仕様は、ハードウェアアーキテクチャ要件を記述するための事実上の標準です。 これはかなり古い標準であり、1998年に企業グループがサーバー管理を標準化するための最初のIPMI仕様を開発しました。
IPMIは、システム内のすべての管理対象コンポーネントにアクセスするための共通メッセージングインターフェイスを提供し、さまざまなタイプの操作（たとえば、温度、電圧、ファン速度の監視、OSコンソールへのアクセスの取得など） 複合体全体の電力管理、ハードウェアSELログの受信（システムイベントログ）、センサーデータの読み取り（SDR）、ハードウェアウォッチドッグの実装のための方法も提供されます。 IPMIは、システム管理バス（SMBus）やInter Integrated Circuit（I2C）などの個々のセンサーアクセス方法の置換または抽象化を提供します。 ほとんどのBMCは、少数のベンダーの独自のIPMIスタックを使用しています。
IPMIのクレーム
このプロトコルには、ネットワーク（IPMI over LAN）経由でアクセスする際のセキュリティの観点など、多くの苦情が蓄積されています。 定期的に、ネットワークはこのようなストーリーに衝撃を受けます。 これは、サービスプロセッサにアクセスした後、サーバーを完全に制御できるようになることです。 復旧モードで再起動し、「root」アカウントのパスワードを変更することを妨げるものは何もありません。 この脆弱性に対する唯一の信頼できる解決策は、IPMIトラフィック（UDPポート623）が専用ネットワークまたはVLANを超えてはならないというルールです。 制御ネットワーク内のアクティビティは、厳密に監視する必要があります。
セキュリティの問題に加えて、データセンターのハードウェア環境は長年にわたって劇的に変化しています。 仮想化、コンポーネントの分解、およびクラウドの広がり。 IPMIに新しいものを追加することは困難です。 管理する必要のあるサーバーが多いほど、プロセス自動化の重要性が高まります。 IPMI over LANに代わるAPI仕様が登場しています。 多くの人がRedFishに希望を持っています。
このAPIは、最新のJSONおよびHTTPSプロトコルとRESTfulインターフェースを使用して「帯域外」データにアクセスします。 新しいAPIを開発する目的は、異種データセンターに適した単一の標準を業界に提供することです。 また、単一の複雑なエンタープライズサーバーおよびさまざまなコモディティサーバーのクラウドデータセンター用。 また、このAPIは現在のセキュリティ要件を満たしている必要があります。
同時に、ハードウェアレベルでの標準はIPMIサポートです。これは、電源投入からオペレーティングシステムのロードから障害（フリーズ、パニックなど）の回復まで、サーバーのワークサイクル全体に関与します。
サーバーの寿命におけるBMCの役割。 この図では、SMSは「システム管理ソフトウェア」の略です。 ここから写真を撮ります 。
OpenPOWERシステムの起動におけるBMCの役割
IPMIハードウェアの中心はBMCチップです。 彼は、電源供給の瞬間からサーバーの操作に関与し、OpenPOWERでのサーバーの初期ロードのプロセスに関与しています。 つまり、システムの電源を入れるにはBMCが必要です。 同時に、BMCの再起動/クラッシュは、すでに実行されているオペレーティングシステムには影響しません。
BMCとPOWER8プロセッサーは、LPC（低ピン数）バスで接続されています。 このバスは、比較的低速な周辺機器とプロセッサを接続するように設計されています。 最大33 MHzの周波数で動作します。 LPCを介して、中央処理装置（つまり、 Hostboot / OPALマイクロコード）は、 BT （p。104）インターフェイスを介してBMC IPMIスタックと通信します。 同じバス上で、POWER8はLPC→SPI（シリアルペリフェラルインターフェイス）接続を介してPNOR（プロセッサNORチップ）から起動可能なマイクロコードを受け取ります。
ブートフェーズでのBMCの役割電源オフ->スタンバイ
最初の起動フェーズは、電源が接続されるとすぐに開始され、BMCが完全にオンになり、ホスト全体の起動を開始する準備が整った段階で終了します。 今後は、OpenPOWERシステムでのBMCソフトウェアの操作全般について説明しますが、特にサーバーではこれらの機能はOpenBMCによって実行されます。 電源が投入されると、BMCはSPIフラッシュからコードの実行を開始し、u-bootをロードしてからLinuxカーネルをロードします。 この段階では、IPMIはBMCで実行され、LPCバスはPNORメモリ（mtdblock経由でマウント）へのホストアクセスのために準備されています。 POWER8チップ自体は、この段階でオフになります。 この状態で、BMCネットワークインターフェイスに接続して、何かをすることができます。
スタンバイ-> OSブート
システムが「スタンバイ」モードで電源ボタンが押されると、BMCはブートの継続を開始し、POWER8チップ内のマスタープロセッサーで「小さな」SBE（セルフブートエンジン）コントローラーを起動して、PNORフラッシュからL3マスターキャッシュにホストブートマイクロコードをロードしますプロセッサ。
ホストブートマイクロコードは、プロセッサバス、SDRAMメモリ、他のPOWER8プロセッサ、OPAL（Open Power Abstraction Layer）プロセッサ、およびOCC （On Chip Controller）と呼ばれるPOWER8に組み込まれた別のマイクロコントローラの初期化を担当します。
このコントローラーについては、BMCにとって特別な意味があるため、詳細に説明します。 Hostbootが作業を完了すると、 Skibootマイクロコードの次のコンポーネントがPNORフラッシュから起動されます。 このレベルは、プロセッサーを同期し、PCIeバスを初期化し、IPMIを介してBMCと対話します（たとえば、FWブートの進行状況センサー値を更新します）。 Skibootは、メインオペレーティングシステムのロード元を選択し、kexec呼び出しで起動する次のPetitbootブートレベルの起動も担当します。
しかし、一歩下がってOCCに戻ってください。 OCCチップは、メインPOWER8コア（チップごとに1つのOCC）とともにIBM POWER8プロセッサーに統合されたPPC 405コアです。 独自の512K SRAM、メインメモリへのアクセスがあります。 これは、温度制御（メモリとプロセッサコアの温度の監視）、メモリパフォーマンスの管理、プロセッサの電圧と周波数の監視を担当するリアルタイムシステムです。 OCCは、これらすべての情報をI2Cバス経由でBMCに提供します。
OCCは正確に何をしますか？
- サーバーコンポーネントの電源状態を監視します。
- コンポーネントの温度を監視および制御します。 過熱した場合、メモリパフォーマンスが低下します（メモリ調整）。
- 必要に応じて、OCCは最大P状態（パフォーマンス状態、 ACPIを参照）を減らすことにより、プロセッサの周波数/電力消費を減らします。 ただし、OCCはPステートを直接指定しません。 オペレーティングシステムがP状態を変更できる制限を設定します。
- 効率的なファン制御のためのBMC電力および温度情報を提供します。
したがって、OCCは、I2Cバスを介して接続されているBMCの情報プロバイダーです。 POWER8（特にOCC）のほとんどのマイクロコードのソースコードは、IBMによって公開されました 。
LPCバスを介してOCCおよび中央プロセッサとやり取りすることに加えて、BMCには他のインターフェイスがあります。 たとえば、BMCチップ上のGPIOは電源とLEDの制御に使用され、I2Cはセンサーの読み取りに使用できます。
上記のすべての相互接続はそれほど複雑ではありません
現在、OpenPOWERファームウェアのほとんどは開いています。 同時に、サービスプロセッサのソフトウェア部分とIPMIスタックは、最近まで独自のものでした。 サービスプロセッサの最初のオープンソースプロジェクトはOpenBMCでした。 コミュニティは彼に熱意を示し、積極的に成長し始めました。 OpenBMCについて、さらに話します。
OpenBMC、その歴史と機能
最後に、OpenBMCのストーリーとその使用方法について説明します。
FacebookでのOpenBMCの誕生
OpenBMCは、2015年にOCPコミュニティの一部としてWedgeスイッチを開発したときにFacebookに登場しました。 当初、BMCソフトウェアは鉄のサプライヤーによって開発されました。 作業の最初の数ヶ月で、BMCの多くの新しい要件が発生しましたが、開発者との調整は難しく、遅延を引き起こしました。 この影響を受け、ハッカソンの1つで、4人のFacebookエンジニアがBMCの基本機能の一部を24時間で実装しました。 生産性とはほど遠いものでしたが、BMCのソフトウェア部分を実装するタスクはハードウェアとは別に解決できることが明らかになりました。
数か月後、OpenBMCはWedgeスイッチとともに正式にリリースされ、しばらくして、OpenBMCソースコードがOCPパートナーシップの一部として開かれました。
その後、FacebookはOpenBMCをNVMe Lightningフラッシュシェルフ、そしてYosemiteマイクロサーバーシャーシに適合させました。 最後の変更では、FacebookはRMCP / RMCP +（IPMI over LANアクセス）を放棄しましたが、HTTP（S）経由のREST APIとSSH経由のコンソールアクセスがありました。 このように、Facebookはさまざまなタイプの機器を管理するための単一のAPIと、新しい機能の実装における大きな柔軟性を手に入れました。 BMCに対する独自のアプローチでは、これは不可能です。
Facebookの概念では、BMCは通常のサーバーですが、限られたリソース（低速プロセッサ、低メモリ、小型フラッシュ）でSoC上で実行されます。 これを念頭に置いて、OpenBMCは特殊なLinuxディストリビューションとして構想され、そのすべてのパッケージはYoctoプロジェクトを使用してソースから収集されます。 Yoctoのすべてのパッケージの説明は「レシピ」に結合され、「レシピ」は「レイヤー」に結合されます。
OpenBMCには3つの層があります。
- 一般レベルのユーザー空間アプリケーション（ハードウェアに依存しない）。
- SoCレベル（Linuxカーネル、ブートローダー、Cライブラリ）。
- プラットフォーム/製品レベル（特定の製品に固有のパッケージ、カーネル設定、センサーのライブラリ）。
BMCでYoctoを使用したのはFacebookが初めてではありません。 独自のDell iDRACは、同じビルドシステム上に構築されています。
OpenBMCは、いくつかのbitbakeコマンドを使用して再構築することにより、あるプラットフォームから別のプラットフォームに簡単に移植できます。 これにより、同じBMCを使用でき、その結果、異なるハードウェアプラットフォームで同じAPIを使用できます。 これは、ソフトウェアスタックがハードウェアに依存するという確立された伝統を破ることができます。
IBMのフォークプロジェクト
OCPコミュニティはOpenBMCのアイデアをすぐに受け入れ、別のOCPメンバーであるIBMが開発に積極的に関与しました。 彼らの努力の結果、 OpenPOWERでプロジェクトが分岐し、2015年8月までに、 AST2400 SoCでのRackspace Barreleyeサーバー向けのOpenBMCの最初のバージョンがリリースされました 。 IBMのエンジニアは断固としてビジネスに取りかかり、新しいプラットフォームにOpenBMCを適合させただけでなく、大幅に作り直しました。 同時に、締め切りが厳しく、開発を容易にするために、Pythonが積極的に使用されました。
変更は、SoC用に再設計されたLinuxカーネル（インストールされたドライバー、デバイスツリーが追加された）を含むプロジェクトのすべてのレイヤーに影響し、ユーザーレベルでは、プロセス間通信用にD-Busが表示されました（FacebookにはD-Busがありませんでした）。 OpenBMCのすべての機能が実装されるのはD-Busを介してです。 OpenBMCを使用する主な方法は、バスインターフェイスにアクセスするためのRESTインターフェイスです。 さらに、Dropbear SSHがあります。
Python Bottleフレームワークを介したREST API（デバッグなど）へのWebアクセスがあります。
1つのプラットフォームから別のプラットフォームへのOpenBMCの移植性が容易なため、RaspberryPIまでの開発ボードを開発に使用できます。 開発を簡素化するために、QEMUエミュレーターのアセンブリが提供されます。
現在、OpenBMCにはSSH経由のやや禁欲的なコンソールインターフェイスがあります。 IPMIは最低限ホストによってサポートされています。 RESTインターフェースは、リモート管理および監視のためにアプリケーションで使用できます。 最も一般的な機能のいくつかは、
obmcutil
コマンドを介して実装されます。
おそらく、BMCを介して実行される操作の90％がサーバーのオン/オフを切り替えています。 OpenBMCでは、これは
obmcutil poweron
および
obmcutil poweroff
。
また、たとえば、
obmcutil
を使用すると、特定のプラットフォームでサポートされている場合、センサーの値とサーバーハードウェア（FRU）に関する詳細情報を確認できます。
obmcutil getinventory obmcutil getsensors
現在、IBMだけでなく、クローズドBMCスタックの回避に関心を持つ他の多くのベンダーもOpenBMCプロジェクトに積極的に参加しています。 IBM自体は、主にP9プラットフォームへの適応に重点を置いています。
OpenBMCの開発の大部分はApache-2.0ライセンスの下にありますが、OpenBMCにはさまざまなライセンスを持つ多くのコンポーネントが含まれています（たとえば、LinuxカーネルとGPLv2の下のu-boot）。 その結果、さまざまなオープンソースライセンスが混在しています。 さらに、開発者は、オープンソースと並行して動作する独自のコンポーネントを最終アセンブリに追加できます。
OpenBMCに関する私たちの見解
上記のテキストからわかるように、OpenBMCに基づいてサービスプロセッサのソフトウェア部分を設計しています。 製品はまだ未加工ですが、サーバーを管理するための最小限の機能は既に実装されており、IPMIを部分的に実装しています（最も基本的なニーズのため）。 この機能セットを備えたサーバーのサービスプロセッサは、数年前に市場に出ていました。
OpenBMCは絶えず変化し、改善されています。ほぼ毎日、gerritサーバーで新しいコミットを確認できます。 したがって、現時点で機能に重点を置くことはあまり感謝されていません。 リファクタリングは継続的に実行され、PythonコードはC / C ++に置き換えられ、より多くの関数がsystemdに転送されます。
通常のサーバーに対するサービスプロセッサに対する態度は、サーバーの寿命における重要な役割のため、BMCにとって一般的ではありません。 systemdとD-Busの使用は、これまでこの分野では一般的ではありませんでした。 新しい時間-新しいトレンド。
私たちにとって最初のタスクは、OpenBMCの現在の状態をプラットフォームに適合させることです。 さらに、お客様が興味を持っているオプションとインターフェイスを使用して、それを改良する予定です。 現時点では機能が制限されているため、開発には非常に多くの方向性があります。 新しい機能が実現したら、OpenBMCプロジェクトに変更をコミットして、コミュニティが使用できるようにします。