2 ポイント 投稿者 GN⁺ 2024-09-04 | 1件のコメント | WhatsAppで共有
  • Computers Are Bad がエンタープライズクラウドをニューメキシコへ移設する過程で、新しいサーバーを購入している
  • 現在使用中の Big Iron サーバーは約10年前の古い機材である
  • 現代のクラウド中心の業界では、Dell PowerEdge と HP ProLiant の仕様を比較することはまれになっている
  • 非ハイパースケールのサーバー市場は、ますます Intel の仕様とリファレンスデザインへと統合されつつある

サーバーとは何か?

  • サーバーは単に大きくて強力なコンピューターなのか、それとも特別な存在なのかという古くからの問いがある
  • サーバーの歴史には多くの産業史が含まれており、状況によって答えは変わりうる
  • サーバーの歴史については、次のような一般化が可能である
    • クライアント・サーバーコンピューティングは主に、単一のコンピューターに複数の端末を接続するタイムシェアリングの進化として始まった
    • 端末がコンピューターと似たアーキテクチャを持つことは期待されておらず、これはクライアント・サーバーシステムにも受け継がれた
    • 2000年代までは、サーバーが異なるOSやアーキテクチャを使うのは一般的だった
  • PC革命によって、1990年代半ばまでにクライアント側コンピューティングの大半は WinTel モノカルチャーとして定着した

サーバーアーキテクチャの変化

  • SPARC と Solaris の組み合わせはサーバーで非常に一般的で、IBM のミニコンアーキテクチャや多様なOSも同様だった
  • Java の主要な商業的貢献の1つは、Solaris/SPARC バックエンド向けにエンタープライズアプリケーションを書きつつ、Unix/RISC や Windows/x86 のような「現代的」なビジネスコンピューティング環境でもコード再利用を可能にした点である
  • 「厚いクライアント」を持つクライアント・サーバーコンピューティングモデルは、サーバープラットフォームと「エンタープライズコンピューティング」の結びつきを生み出した
  • かつてサーバーに限定されていたアーキテクチャは次第にニッチ市場となり、コストや性能の面でPCアーキテクチャと競争しにくくなった
  • サーバーソフトウェアの一般的なアーキテクチャは、「垂直スケールと高可用性システム」から「水平スケールと緩和された安定性要件」へ移行し、エンタープライズ級コンピューターの利点は大きく減少した
  • 今日では多くの場合、サーバーは単に大きなコンピューターにすぎない
  • サーバーはマルチプロセッサソケットを備えた SMP または NUMA である可能性がはるかに高い
  • SAS やハードウェア RAID の時代は薄れつつあるが、サーバーは依然としてクライアントより複雑なストレージコントローラーやトポロジーを提供している
  • サーバーはほぼ例外なくアウト・オブ・バンド(OOB)管理を提供する

アウト・オブ・バンド管理

  • アウト・オブ・バンド管理(OOB)は、クライアントではほとんど見られない機能である
  • 別個の小さな管理用コンピューターによって、サーバーへリモートアクセスできるようにする
  • OOB 管理はOSや一般的なコンポーネントを必要としない
  • ほとんどのサーバーはリモートコンソールを提供し、ローカルのモニターとキーボードに接続されているかのように操作できる
  • OOB 管理製品は「仮想メディア」機能を提供し、ISO ファイルをアップロードして物理デバイスのように認識させることができる

アウト・オブ・バンド管理(帯域外管理、Out-of-Band Management)

  • アウト・オブ・バンド(時には無人管理とも呼ばれる)は、クライアントではほとんど耳にしない機能を指す
  • 別個の小さな管理用コンピューターを通じて、サーバーの電源が切れていてもリモートアクセスが可能である
  • 「帯域外(Out-of-band)」と「帯域内(in-band)」という用語は、ネットワーキングや通信で一般に使われる意味から来ているが、実際にはその意味は変化してきた
    • 帯域外管理とは、OSや汎用コンポーネントを必要としないことを意味すると捉える方がよいかもしれない
  • 帯域内管理の非常に標準的な例は SSH で、コンピューター上のソフトウェアが提供するサービスである
  • 一方、帯域外管理は専用のハードウェアとソフトウェアスタックによって提供され、OSや伝統的な意味でのCPUの協調を必要としない
  • 今日の帯域外管理のもっともよい例は、多くのサーバーが提供するリモートコンソールである
    • 基本的には組み込みの IP KVM であり、ローカルに接続されたモニターとキーボードがあるかのようにマシンを操作できる
  • 多くの OOB 管理製品は「仮想メディア」も提供しており、ISO ファイルを管理インターフェースにアップロードして、実際のデバイスのようにコンピューターに見せることができる
    • これはOSのインストールに非常に便利である

OOB 管理の歴史

  • OOB 管理はコンピューター史の中でも興味深い小領域である
  • 実際、ビジネスコンピューティングの歴史全体の中に類似の機能を見いだせるほど、新しい発想ではない
  • 時間がたつにつれて、OOB 管理はより単純で退屈なものになっていった
  • 1980年代後半〜1990年代初頭以降、サーバーの共通機能として以下があった
    • LCD マトリクスディスプレイや LED インジケーターグリッドのように、ハードウェア状態に関する低レベル情報を提供するローカルのオペレーターインターフェース
    • 初期ブートローダーや永続的な低レベル管理システムへアクセスできるシリアルコンソール
    • アーキテクチャによってスタック内での位置はさまざまだが、マシンのワークロードを遠隔管理するための、より高レベルな管理システム
  • OOB 管理の現在
    • ほとんどのサーバーは、冗長コンポーネント(たとえばファンや電源ユニット)に障害が発生したかどうかを前面パネルで知らせられる
    • しかし、冗長化されオンライン交換可能なコンポーネントの数は、1990年代の「CPUを含むほぼすべて」から、場合によってはファン程度にまで減っている
    • ヘッドレスマシンでのOSインストールや保守の一般的な方法として残っているため、シリアル管理はいまもかなり一般的である
    • しかし多くの場合、OOB 管理はプロセッサアーキテクチャとまったく同じように Intel IPMI へ統合されている

IPMI のややこしい点

  • IPMI は実装ではなく仕様である
    • 大手ベンダーの多くは、IPMI コア仕様を超える機能を備えた独自の IPMI 実装を持ち、HP iLO、Dell DRAC などの奇妙な略称で呼ばれている
    • こうしたベンダー固有の実装は IPMI より古いため、「単に IPMI」と言うのは完全には正しくない
    • 一方、新興メーカーはそれを IPMI と呼ぶ可能性が高く、その場合はファームウェアベンダーの標準製品であることも多い
  • IPMI ソフトウェアは通常、ベースボード管理コントローラー(BMC)と呼ばれるプロセッサで動作し、IPMI と BMC という用語が同義のように使われることもある
  • Lights-out management(LOM)はほとんど役に立たない用語だが、HP(E) が好んで使い、その IPMI 実装を Integrated Lights-Out と呼ぶため生き残っている
  • BMC は、クライアントコンピューターにも存在する構成要素であるシステム管理コントローラー(SMC)と混同してはならない
    • SMC はファン速度制御のような作業を処理するために使われるいくつかの用語の1つである
    • BMC と SMC には関連する歴史があり、実際には BMC がほとんどのサーバーでこれらの機能を担当している
  • IPMI は2つのインターフェースを規定している
    • ネットワークまたはシリアル接続で利用できる帯域外インターフェース
    • ドライバー経由でOSから利用できる帯域内インターフェース(CPU と BMC の通信には LPC バスを使う。これは現代の多くのコンピューターに残る ISA の奇妙な小さな名残である)
  • その結果、Linux の ipmitool のように、OS上で動くツールから IPMI とやり取りできる
  • IPMI が、利便性のために実行中のOS向けローカルインターフェースを持つ完全に独立したシステムだと理解していないと、何が起きているのか少し混乱しやすい

IPMI の機能

  • IPMI は今やほとんどが Web アプリになっている
    • Web インターフェースは便利すぎて断れない
    • 専用クライアントソフトウェアを備えた IPMI 製品も多いが、あらゆる機能を組み込み Web アプリケーションへ移植しつつある
  • Web インターフェースの品質には大きなばらつきがあるが、たいていはあまり良くない
  • IPMI Web インターフェースへのアクセス方法
    • 市場に出回るほとんどのサーバーには、「IPMI」「management」などとラベル付けされた専用の Ethernet インターフェースがある
    • IPMI を使う最善の方法は、管理ネットワークインターフェースを専用の物理ネットワークに配置することだ
      • セキュリティと信頼性のためである(主ネットワークに性能や安定性の問題があっても、IPMI には継続してアクセスできる必要がある)
    • ただし専用の物理ネットワークには時間も空間もコストもかかる
      • 「管理ネットワーク」は通常のネットワーク機器上の VLAN である可能性が非常に高い
      • これは AT&T が共通通信事業者交換アレイ(CCSA)と呼んだものに似ている
      • 独立した私設ネットワークのように動作するが、実際の機器は他のすべてと共有し、分離はソフトウェアで実装される
  • IPMI サイドバンドネットワーキング
    • サイドバンド管理では、BMC はOSが使用するのと同じ NIC と直接通信する
    • 実装方法は少し奇妙である
      • NIC は2つの異なるインターフェースであるかのように振る舞い、ホストトラフィックと同じパケットストリームに IPMI トラフィックを混在させるが、別の MAC アドレスを使用する
      • このため他のネットワーク機器からは、いつものように2つの異なるネットワークインターフェースが使われているように見える
    • IPMI とアプリケーショントラフィックの分離を弱めることには、明白なセキュリティ上の考慮事項がある
  • IPMI のセキュリティ問題
    • 多くの IPMI 実装はセキュリティ上の悪夢であることが判明している
    • 信頼できない人物には絶対にアクセスさせてはならない
  • IPMI のネットワーク機能
    • ネットワーク機能の詳細は IPMI 実装ごとに異なるが、UDP 623 には検出や基本コマンドに使える標準インターフェースがある
    • SSH や Web インターフェースを備えることが多く、リモートコンソールには VNC が非常によく使われる

IPMI の基本機能

  • ネットワーク経由でも帯域内 IPMI クライアント経由でも、IPMI で行える便利な基本機能がある
  • 忘れっぽく記録をきちんと残さない人にとって便利な機能の1つは、FRU やベンダーの部品番号レベルで、システムを構成するハードウェアモジュールを列挙できることだ
  • センサー、電源状態、ファンなどの基本的なハードウェア機能ともやり取りできる
  • IPMI は標準のウォッチドッグタイマーを提供しており、OS上で動くソフトウェアと組み合わせることで、アプリケーションが異常状態になったときにサーバーをリセットさせることができる
  • システムが起動し、接続してウォッチドッグタイマーを無効化できるだけの十分に長いタイムアウトを設定する必要がある

IPMI と日常的なクライアントコンピューターの関係

  • IPMI はエンタープライズサーバーでは非常に一般的だが、それ以外では非常にまれである
  • スペースや騒音の許容度が 1U ピザボックス向けではない人には不満な点である
  • 小型または低消費電力のコンピューターにこだわるなら、IPMI なしでやっていくことになる

Intel ME と AMD ST

  • 事実上すべての Intel および AMD プロセッサに存在する OOB 管理コントローラーである
  • Intel ME(Management Engine)は Intel Active Management Technology(Intel AMT)を有効にする構成要素である
  • AMT はクライアントマシン向けに OOB 管理の普及を試みたもので、IPMI とほぼ同じ機能を提供する
  • ただし成功度ははるかに低く、その大半は価格のせいだろう
    • Intel はほぼすべての AMT 機能を、非常に高価なエンタープライズ管理プラットフォームと組み合わせた利用に限定していた
  • オープンソースの AMT クライアントは存在するが、次に直面する問題は、AMT を実際に利用できるマシンを見つけることだ

Intel AMT のサイドバンド管理機能とセキュリティ問題

  • Intel AMT にはサイドバンド管理機能があり、そのため AMT が動作する Intel ME コンポーネントにもサイドバンド管理機能があるという事実は、セキュリティコミュニティでかなりの懸念の的となってきた
  • 緩和要因として、サイドバンド管理はプロセッサ、メインボードチップセット、NIC のすべてが AMT 対応である場合にしか利用できない
    • これら3つのデバイスの選択肢は、vPro バッジ付きの Intel 製品に限られる
    • コンシューマー機器で Intel NIC が人気でないことだけでも、サイドバンドアクセスがほぼ不可能であることを意味する
  • vPro は比較的上位のプロセッサとチップセットにも限定される
    • 悪い知らせは、ホームラボで AMT を使うのが難しいという点だが、実際に使っている人も確かにいる
    • 良い点は、コンシューマー機器上の Intel ME がサイドバンドネットワーキング経由でアクセス可能だという広く報じられた「事実」は一般には正しくなく、それは Intel のソフトウェアライセンス以外の理由によるということだ

Intel ME が存在する理由

  • AMT がなければ、実際には OOB 管理機能を持たない Intel ME 自体についての奇妙な疑問が残る
  • なぜほぼすべてのプロセッサに Intel ME があるのか?
    • 推測だが、Intel ME は主に、セキュアブートや DRM のようなものに使われる信頼実行コンポーネントをホストし管理する便利な方法として存在しているように見える
    • これらの機能はすべて ME と同じプロセッサ上で動作し、ある程度共通の技術スタックを共有している
  • したがって Intel ME の「管理」の部分はかなり痕跡的なものであり、セキュアコンピューティング基盤の一部である

Intel ME を正当化する話ではない

  • これは、第三者がまったく監査できず、過去に重大なセキュリティ脆弱性を抱えていた Intel ME を擁護するものではない
  • 私たちは皆、2ベンダーのどちらかのプロセッサアーキテクチャを使っているので、Intel にはより良いものを作る動機があまりない
  • ARM が答えだと言う前に、コンシューマー機器で使われる最新の ARM SoC にもほぼ同じ機能があることを思い出してほしい

参考:ヘッドレスの定義

  • 「ヘッドレス」の定義は厄介で、あまりこだわりすぎるべきではない
  • 人は「ヘッドレス」を、モニターとキーボードが接続されていないことだと言いがちである
  • しかしスライドアウト式ラックコンソールや IP KVM は長年一般的だったので、ハイパースケールではない環境では真のヘッドレスシステムは思うほど多くないことを念頭に置くべきである
  • これは一因として、シリアルコンソールの使用がひどくつらい作業なので、一般的なコンピューター運用担当者はそれを避けるために多くのことをするからである

GN⁺ の意見

  • この記事は、サーバーの定義と歴史について興味深い洞察を与えてくれる。サーバーは単なる大きなコンピューターだという一般的な認識とは異なり、サーバーは長い歴史の中で特別な役割を担ってきたことを示している。
  • サーバーの歴史をたどると、技術の進歩とともにサーバーの概念がどのように変化してきたかが分かる。特に、PC革命以降、サーバーとクライアントの境界が次第に曖昧になっている点は興味深い。
  • 帯域外管理はサーバー特有の機能であり、OSやCPUの助けがなくてもサーバーを管理できる。これはサーバー管理者にとって非常に有用な機能になりうる。
  • 最近では、Intel IPMI を中心に OOB 管理技術が標準化されつつある。これはサーバー管理の利便性を高める一方で、1社に依存するリスクもある。
  • 類似の OOB 管理機能を提供する他のソリューションとしては、HP の iLO、Dell の iDRAC などがある。特定ベンダーに依存したくないなら、こうした代替案も検討する価値がある。

1件のコメント

 
GN⁺ 2024-09-04
Hacker Newsの意見
  • IntelはAMDと比べてCPUとGPUの性能で後れを取っている

    • 例外的にN100シリーズCPUは低消費電力かつファンレスのアプリケーションに適している
    • ほとんどの組織は既存環境を更新するためにIntel CPUを購入している
    • vSphereのEVC機能により、CPUアーキテクチャ間でのホットマイグレーションが可能
  • Intel NICは全体的に優れており、コンシューマー向けデバイスでも人気がある

    • Intel CPUを搭載したPCやノートPCには、ほぼ常にIntel NICが含まれている
  • サーバー購入時にはSupermicroが良い選択肢

    • 安価で、フォームファクタ、シャーシ、コンポーネント、スロット数などの面で高い柔軟性を提供する
    • ただし、サポートはDell/HPEより信頼性が低いため、冗長構成に向いている
  • IPMI仕様はRedfishに置き換えられつつある

    • Redfishはより完全で、安全かつ標準化されたAPIを提供する
  • Supermicroのハードウェアは依然として優れているが、最近のHindenburgの調査ではいくつかの問題点が指摘されている

  • IPMIはエンタープライズサーバーでは一般的だが、家庭用ではまれ

    • AtomベースのSupermicro MicroATXボードとNoctuaファンを使えば静かに冷却できる
  • IPMIポートはメインのLANに接続しないほうがよい

    • 分離された環境で有用に活用できる
  • IPMIのないマシンにリモートアクセス機能を追加するには、30ドルのRISC-V NanoKVMを使える

    • HDMIキャプチャ、イーサネット/WiFi、ATX電源制御などを提供する
  • 90年代後半のIntelサーバー導入経験の共有

    • LANDesk Server Manager ProソフトウェアとEmergency Management Cardを使用
    • EMCのデフォルトパスワードは"calvin"だった
  • IPMIのようなソリューションは良いが、標準シリアルインターフェースのほうを好む

  • IPMIは長期的にはハードウェア支援が不足している

    • IPMIハードウェアに独自のOSをロードできれば、より有用になるだろう
  • Intel MEとAMD PSPはCPU初期化で重要な役割を果たす

    • 初期化の複雑さが高いため、別個の組み込みコアで処理するほうが理にかなっている
  • DellはIPMIをRedfishで置き換えようとしている

    • RedfishはHTTP/JSON REST APIを使用する
  • IPMIはホームラボ用途では約5Wの待機電力消費が問題になる

    • PiKVM(V2)とRaspberry 4を使ってリモート管理機能を試す予定
  • IPMIのデフォルトキーは重大な問題

    • サプライチェーン内で追加のキーがインストールされると、リモート管理が可能になる恐れがある