# Third Party Integration, Telemetry & APIs Navigation: [[Open Compute Project]] | [[データセンターテレメトリ]] | [[ゼロトラスト]] ## 概要 Open Compute Project(OCP)に提出された 27 ページのホワイトペーパー(v1.0、2025 年 10 月)。Google・Microsoft・Oracle・NVIDIA の 6 名が共著する。査読論文ではなく、業界標準の策定を呼びかける提案文書であり、実測評価や定量データは含まない。テナント(顧客)がコロケーション事業者の設備テレメトリを受け取る場面を対象に、対象点の棚卸し、通信方式、信頼境界の越え方を整理し、「ゼロトラスト・テレメトリデータ交換」の仕様策定を業界へ求める。 ## 背景と動機 電力使用量の急増を背景に、[[PUE]] と [[WUE]] の最適化、規制対応が必須になったと著者らは述べる。テレメトリの用途は次の 4 つに整理される。 - **インシデント対応**: テナントへのリアルタイム通知と、建物全体の停電を避けるためのテナント横断の負荷遮断・協調。 - **PUE・WUE 報告**: EU Code of Conduct、iMasons Climate Accord、マルチテナント施設での報告義務。テナント横断の PUE 最適化。 - **ワークロードと過渡応答**: テナント・建物・キャンパス単位の負荷安定性の評価。コールドアイル温湿度の維持。 - **排出報告**: 発電機の稼働時間・燃料使用量・排出量。欧州の規制当局が報告を求める方向にあると述べる。 顧客側の利点として、電力・資源消費のプロファイル、ホットスポットの特定、低稼働サーバの集約、旧機材の退役、オフピーク電力への負荷移動を挙げる。 ## 接続システムと信頼境界 制御系の階層化に Purdue モデル(産業制御システムの 5 レベル)を用いる。従来モデルに Level 3.5 を足し、企業(IT)層と OT 層の間に DMZ を置く。網の種別ごとの要点は次のとおりである。 - **局所隔離網(Level 0)**: DLR などの IO 網。バックプレーンのアクセスポートを無効化し、網のブリッジを禁じる。 - **ビルディング設備網**: セグメンテーションと 802.1X による機器認証。Modbus や BACnet などのオープンプロトコルは、書き込みパケットの遮断や監視を加えて慎重に扱う。 - **サイト網**: Level 2 機器に限り、機器認証と暗号化を条件に接続する。 - **DMZ**: IT と OT の境界。ファイアウォールとネットワーク監視が必要。 - **企業網**: 境界を越えるサービス(SMTP、ID サービス、MQTT などのリモートデータ)は明確に定義して制御する。 ## 共通インタフェース 独自 API は統合コストと保守負担を増やすため避けるべきだとする。挙げられるプロトコルは MQTT、RESTful API、Redfish の 3 つで、いずれも暗号化と認証が必須である。要件として TLS と mTLS を置く。収集方式は Pull(ポーリング)、Push、Pub/Sub(MQTT の基盤)に分類される。 ## テレメトリ対象点の階層 - **ベースビルディング**: 複数テナントまたは複数データホールに共通の設備。受電・変電所、非常用発電(専用系統の場合は該当テナントにのみ提供)、中央ユーティリティプラント(PCWS/PCWR 温度、ポンプ速度、補給水貯水量、WUE、冷凍機の状態)。 - **データホール**: テナント専用のセキュア境界。UPS・PDU・バスウェイ・RPP の電圧・電流・周波数・電力、CRAH の RAT・SAT・ファン速度・EWT・LWT、液冷(CDU 状態、TCS の供給・戻り温度、CDU と ラックの差圧、流量、二次ループの水質、漏水検知)、入退室機器。 - **機械設備の監視**: 中央冷水プラント、CRAC/CRAH、ホット/コールドアイルの封じ込め(差圧で気流の混合を検知)、ラック・エリアセンサ(入口温湿度、ホットスポット、漏水)。予知保全、冷却設定値の調整による PUE 改善、規制対応、根本原因分析への効用を述べる。 - **電気設備の監視**: 受電盤 → UPS → PDU/RPP の階層。電力品質、バッテリ状態、バイパス状態、ラック負荷、回路の負荷バランス、容量計画、課金配賦(チャージバック)に使う。 ## ゼロトラストによる境界越え 運用者の BMS とテナントの IT ワークロード網の間の伝送は両者に脆弱性をもたらすため、「決して信頼せず、常に検証する」原則に立つ標準が必要だと述べる。構成案は 3 つある。 - **データダイオード(一方向ゲートウェイ)**: 物理的に一方向を強制する。最も安全だが、双方向の適応制御ができず、読み取り専用の基本メトリクスに限られる。 - **メッセージブローカー / API ゲートウェイ**: Kafka などを DMZ または隔離エンクレーブに置き、BMS とテナント網は互いに直接通信せずブローカーとのみ通信する。マイクロセグメンテーションと、トークン・証明書による都度の明示的検証で成り立つ。 - **アプリケーション層のカプセル化**: MQTT や保護された REST で、温度や PUE 値のみなど交換データを細かく制御し、最小権限を実現する。 専用の物理配線だけでは解決にならず、アプリケーション層の厳格な制御が要るとする。ただし「普遍的に採用される解はまだ定まっていない」と明記しており、3 案の優劣や実装上の遅延・スループットの検証は示されない。実時間の調整に必要な報告頻度を満たす必要がある、という要件のみが述べられる。 ## 標準化の呼びかけ 運用者、クラウド事業者、ベンダー、業界団体(iMasons、ASHRAE)に、次の 3 目標で仕様を策定するよう求める。 1. **セキュア構成の標準化**: DMZ のメッセージブローカーと、MQTT または REST 上の mTLS を義務づけ、完全性と否認防止、最小権限を保証する。 2. **データスキーマと頻度の定義**: PUE・WUE・回路電流・コールドアイル温度などの標準スキーマと最小報告頻度。 3. **監査性とコンプライアンス**: データ交換の継続的な監視とログで、根本原因分析と国際的な報告義務への対応を容易にする。 付録には、入退室などのサービス要求の標準 API 機能(要求の作成、ケースノートの双方向やり取り、ファイル添付、状態照会、クローズ、アクセス失効、更新取得)と、UPS・PDU・バスウェイの電力点(周波数・電圧・電流・皮相電力・力率)を並べた共通点リスト例がある。点リストの報告頻度欄は空欄で、実際の仕様は将来の作業とされる。 ## 位置づけと限界 - 提案文書であり、提案した構成の実装・評価は示されない。テレメトリの粒度・頻度・遅延についての数値は無い。 - 対象は設備(電力・冷却・入退室)のテレメトリで、GPU やワークロードの計装は扱わない。[[@2025__NERC__Characteristics and Risks of Emerging Large Loads]] が系統運用者側の可観測性欠如を最重要リスクとして挙げる点とは、データセンター側に共有の仕組みが要るという問題意識が重なる。 - 引用文献は 3 件(VMware ブログ、DCD の IEA 報道、電気機器メーカのブログ)のみで、一次資料は乏しい。 ## 出典 - [[.raw/reports/ocp-third-party-integration-telemetry-apis-2026-09-19.pdf]]