なぜソフトウェアがないのか

私たちは何十年もの間、仮想化ハイパーバイザーを備えたサーバーを細分化するソフトウェアを使用して、比較的大きな鉄片上で多くの小さなワークロードを実行してきました。

これは、大不況の最中に X86 サーバーにとって恩恵でした。当時、サーバー仮想化テクノロジは (まだ完全ではありませんでしたが) 実稼働環境に導入できるほど成熟しており、サーバーの統合とサーバー使用率の向上が可能になり、一部の企業では 1 ～ 2 世代のサーバーをスキップすることができました。新しいアイロンに実際にはお金を費やすことができなかったときに、サーバーのアップグレードを行いました。

では、なぜソフトウェアを使用して多数の安価なサーバーを緊密に結合し、共有メモリのチャンクとそれに関連するコンピューティングを作成して、単一マシンよりも大きなワークロードを実行しないのでしょうか? 疎結合分散コンピューティング システムよりも共有メモリ空間の方がプログラミングがはるかに簡単なので、これは私たちにとって少し困惑します。 少数のソケットと数千のスレッドを備えたマシンを使用し、低レベルのソフトウェアでリソース割り当てを管理したいと思いませんか? 怠けてスケールアップできるのに、なぜアプリケーションやデータベースをスケールアウトする必要があるでしょうか?

NUMA システムをオンザフライで作成するテクノロジーは長年にわたって存在していました。Virtual Iron、RNA Networks、ScaleMP を覚えていますか? そしておそらく、TidalScale で最高潮に達しました。TidalScale は、本質的に同じストーリーに独自のひねりを加えてアイデアを再検討しており、2012 年 3 月に Ike Nassi、Kleoni Ioannidou、Michael Berman によって設立されました。

ちなみに、市販の X86 マシンから仮想 NUMA サーバーを作成していた他の 3 つのソフトウェア会社はすべて消滅しました。

2001 年に設立された Virtual Iron は、2009 年 5 月に Oracle の巨大な口の中に消えました。2006 年に設立された RNA Networks は、2011 年 6 月に Dell に吸収され、そのサーバー メーカーが少しいじっただけで、その後そのことについて聞くことはなくなりました。また。 そして、2003 年に設立された ScaleMP は、2015 年に The Next Platform が設立された時点では、その名を冠した NUMA ハイパーバイザーによって HPC 分野でまだかなり好調でしたが、ScaleMP は 2021 年 6 月に密かに SAP に買収されました。 (これに関する発表はありませんでした)私たちは気づいている。 ）

Nassi は TidalScale の重鎮であり、現在も会長兼最高技術責任者を務めています。

ニューヨークのストーニー ブルック大学でコンピューター サイエンスの学士号、修士号、博士号を取得した後、ナッシはミニコンピューターのイノベーターである Digital Equipment のエンジニアを務め、1980 年代にはスーパーコンピューティング NUMA システムのイノベーターである Encore Computer で副社長を務めた後、Apple に入社して支援を行いました。 MacOS オペレーティング システムと言語を開発します。 (ナッシは、Ada プログラミング言語の作成者の 1 人で、Apple Newton ハンドヘルド用の Dylan プログラミング言語の作成に貢献しました。) 彼は 2001 年にメッシュ ネットワーキングのパイオニアである Firetide を設立し、その後、SAP Research 部門の主任研究員に就任しました。 2005 年から 2011 年まで勤務した ERP ソフトウェア大手。

ナッシは、カリフォルニア大学サンタクルーズ校でコンピューターサイエンスの非常勤教授を長年務めています。

TidalScale は 2 回のベンチャー資金調達ラウンドで 4,300 万ドルを調達し、2016 年にはゲイリー・スマードンを最高経営責任者として迎え入れました。 Smerdon は AMD の長年の半導体幹部であり、その後、Marvell、Greenfield Networks (Cisco Systems に買収)、Tarari (LSI Logic に買収され、6 年間さまざまな幹部職を務めた)、Fusion-io、および Pavalion Data Systems で勤務しました。 。

私たちは TidalScale 3.0 が立ち上げられたとき、つまりコロナウイルスのパンデミックの真っ最中に Next Platform TV を制作していたときにスマードンと話をしました。 そして残念なことに、私たちは同社が昨年リリースした TidalScale 4.0 について適切な報道を行っていませんでした。 しかし、私たちはリリースされたばかりの TidalScale 4.1 リリース中にそうしています。

同社は、2016 年に仮想 NUMA サーバー向けの最初の HyperKernel と関連システム管理スタックを発表し、2017 年に 2.0 リリースをリリースしましたが、2019 年 9 月の TidalScale 3.0 製品で、構成可能な NUMA マシンのスケーラビリティが向上しました。 HyperKernel。ソフトウェア定義の NUMA サーバー全体で最大 64 TB のメモリを備え、NUMA クラスター内の任意のノードで最大 12 TB、最大 128 TB がアドレス可能です。 これは、現時点で TidalScale がサポートする唯一の CPU である Intel の Xeon SP サーバー アーキテクチャの制限です。

理論上、TidalScale が HyperKernel で AMD Epyc、IBM Power、または Arm サーバー CPU アーキテクチャをサポートすることを妨げるものは何もありません。 しかし実際には、スタートアップは注力する必要があり、インテルが直面しているすべての競争にもかかわらず、データセンターでは依然として Xeon SP アーキテクチャが主流です。

TidalScale NUMA クラスターでは、サーバー ノードはコンピューティングまたはメモリの点で同じ構成である必要はありません。 TidalScale 3.0 では、NUMA クラスター全体で最大 128 個のソケットが許可されました。 明らかに、これらの最大値を使用すると、非対称的な方法でさまざまなサーバー ノードを使用して NUMA クラスターを作成したり、HPE、IBM などの NUMA ハードウェア ベースのクラスター販売業者がクラスター内のすべてのノードを同じ。

TidalScale 4.0 リリースでは、これらの容量がすべて 2 倍になりました。 したがって、ソフトウェア定義の NUMA クラスター全体で、特定のノードに最大 24 TB、最大 256 個のソケット、合計最大 128 TB のメモリを搭載できます。

ある意味、TidalScale はハードウェアの潮流に少し逆らっているのです。 他のいくつかの見方をすると、「ユーバーバイザー」や「ハイパーカーネル」、あるいは Virtual Iron、RNA Networks、ScaleMP、TidalScale が備えているハイパーバイザーのようなものを呼び出すのに、今ほど適した時期はありません。個人的に作成されたもの。

さらに、TidalScale の HyperKernel 内部のいくつかの革新により、それは以前のバージョンと比べてユニークなものになっており、誰かが会社を買収してそこに居座らない限り、このソフトウェアベースの NUMA クラスタリング テクノロジーがさらに普及する可能性があります。特に、高帯域幅と低遅延を提供する PCI-Express、イーサネット、および InfiniBand ネットワークでは重要です。

まず、今日のデータセンターにおけるコンピューティングと NUMA クラスタリングの性質、および多くの場合における NUMA の必要性を軽減する方法について話しましょう。

まず、データセンター市場に残っている少数の CPU 設計者は、数十年にわたってより優れた NUMA ハードウェア設計を実装してきました。これには実際、より多くの、より高速なコヒーレントな相互接続を追加することが必要でした。これは、トランジスタの小型化により、より多くのものをダイ上に詰め込むことができるためです。 現時点では、2 ソケットの NUMA システムにはオーバーヘッドがほとんどなく、X86 アイアンで実行されるオペレーティング システム (Linux および Windows Server) は、NUMA を活用できるようにかなり前から調整されています。 インテルは、4 ソケットおよび 8 ソケット システムを接着剤なしでサポートします。つまり、外部チップセットを追加する必要はありません。

今後の「Sapphire Rapids」Xeon SP では、ソケットあたり少なくとも 60 個の使用可能なコアと、256 GB のメモリ スティックでソケットあたり 4 TB、512 GB メモリでソケットあたり 8 TB をサポートできる 8 つの DDR5 メモリ コントローラが期待されます。スティック。 これは、以前の数世代の Xeon SP と比較して非常に高密度のソケットです。 また、Intel は 8 ウェイ NUMA を接着剤なしでサポートする予定です。これは、最大 480 コア、960 スレッド、および 64 TB を接着剤なしでサポートすることを意味します。 これは現代の標準からするとかなり太いノードです。

「Denali」Power10 ベースの Power E1080 サーバーを使用すると、IBM は、1,920 スレッドで、X86 コアの約 2 倍の作業を実行する 240 コアをサポートできます (IBM は、Power8 および Power9 と同様に、Power10 で 8 方向の同時マルチスレッドを実行します)チップ)、16 ソケット全体、およびそれらのソケット全体で最大 64 TB の物理メモリ。 IBM は、Power10 アーキテクチャ上で最大 2 PB の仮想アドレス指定を備えているため、必要に応じていつでもメモリを増やすことができますが、私たちが知る限り、そのようには感じられず、512 GB の差動 DIMM を製造する予定はありません。 DDR4 メモリに基づいています。 現時点では 256 GB DDIMM が最大です。

これらのハードウェアベースの NUMA サーバーは決して安くはありません。そのため、HPE と IBM は、リレーショナル データベースを利用した大規模なバック オフィス エンタープライズ アプリケーション スタックの下にあるデータベースをサポートするために、依然としてこのサーバーを製造しています。 最近、SAP HANA インメモリ データベースが NUMA Iron の売上を大きく伸ばしています。

しかし、各ソケットがより強力になり、ある程度の量の NUMA がチップに組み込まれているにもかかわらず、ハードウェア NUMA クラスターの費用と厳格な構成が TidalScale にチャンスをもたらしています。 そして、TidalScale HyperKernel の中心となるワンダリング仮想 CPU と呼ばれる発明も同様です。

共有メモリ空間を提供し、サーバー仮想化ハイパーバイザーによって分割されたハードウェア ベースの NUMA アーキテクチャでは、仮想マシンはコンピューティング、メモリ、および I/O で構成され、それらのリソースに固定されます。 その VM 構成の外部にあるデータはすべてその VM にページングされる必要があり、これにより遅延が発生します。

Nassi と彼のチームは、HyperKernel を使用して、新しい種類の仮想 CPU を作成しました。これは、カーブアップ ハイパーバイザー上で実行されるプログラムではなく、一連のレジスタとポインタが割り当てられた低レベルの計算抽象化です。 これは非常に小さな抽象化であり、イーサネット パケット内に収まるメモリの 1 ～ 2 ページです。 アプリケーションの実行中にこれらの仮想 CPU が無数に作成され、データをファット仮想マシンに移動する代わりに、これらの仮想 CPU はサーバー ノード上を飛び回り、ソフトウェア定義の NUMA クラスター内のノードにリンクされたネットワーク全体を飛び回って、データは、アプリケーションで次の操作を実行する必要があるということです。

このさまよう vCPU アーキテクチャについては、このホワイトペーパーで詳しく説明されていますが、核心は次のとおりです。「TidalScale システムの各 vCPU は、データが物理的にどこに存在していても、必要なデータにアクセスできる場所に移動します。TidalScale システムが大規模になると、ワンダリングに使用できる物理 CPU と RAM が増えるほど、ワンダリング vCPU は大量のデータを処理するための他のオプションと比較してより効率的になります。」

効率は、実行中のアプリケーションやデータベースでの計算とデータ アクセス パターンを研究する機械学習アルゴリズムによって部分的に得られ、ベクトル演算ユニットがデータを束ねて並列処理できるのと同じように、vCPU を集約してデータにディスパッチできます。

つまり、たとえばファット データベース管理システムやインメモリ分析を実行するために、大きな NUMA サーバーの共有メモリ スペースが必要な場合、顧客は通常の Xeon SP サーバーとイーサネット スイッチングからシステムを構築できます。ハードウェアベースの NUMA システムよりもコストを節約できます。

「顧客からは、全体のコストが約 50% 削減されたと言われています」とスマードン氏は The Next Platform に語ります。 「そして、IBM Power Systems と比較すると、オールインによる節約効果ははるかに高く、おそらく全体で 60% ～ 75% のコスト削減になると思います。」

ScaleMP が 10 年前に追求していたような他のユースケースも考えられます。 多くの HPC クラスターには、数百または数千の 2 ソケット X86 ノードがあり、さらに、適切に実行するためにより多くのメモリ容量を必要とするワークロードの部分用に、より重い NUMA アイアンに基づく数十のファット メモリ X86 ノードがあります。

これらのファット ノードが、汎用の 2 ソケット サーバーから必要に応じてオンザフライで構成できるとしたらどうなるかを想像してみてください。 さらに良いのは、必要に応じて、実際にファットなメモリ ノードのみのクラスタを作成することも、スキニー メモリ ノードとファット メモリ ノードを組み合わせてクラスタを作成することもできます。 ワークロードが変化すると、NUMA クラスター構成も変化する可能性があります。

サーバーの最も信頼性の低い部分は何ですか? プロセッサーですか？ システムソフトウェアですか？ ネットワークですか？ いいえ。 メインメモリです。 そして、その主記憶がますます高密度になるにつれて、宇宙線やアルファ粒子がビットを反転させ、あらゆる種類の大混乱を引き起こすことが容易になってきています。

スマードン氏は、DRAMチップの容量が増加するにつれてDRAMの信頼性がますます低下していると述べ、2017年のAMDの調査で信頼性が5.5倍低下したという数字を引用した。同時に、サーバーのメインメモリの量も減少している。奇妙なことに、Intel は Optane 3D XPoint メイン メモリをサポートするためにメモリ コントローラを微調整する必要があったため、Intel が行ったことの 1 つは、Optane をアーキテクチャに押し込むことができるようにエラー修正ビットをバックオフすることであり、その結果、 Xeon SP チップのメモリでは、実行時に修正不可能なエラーが発生する割合が高くなります。 これらをすべて掛け合わせると、Xeon SP サーバーのメモリ障害率は 10 年前の約 100 倍になる、と Smerdon 氏は言います。

そして、これに関連するあらゆる種類の恐ろしい話があり、これらのエラーが最新の分散コンピューティング プラットフォームに固有のフォールト トレランス メカニズムでカバーできると言っても、簡単に軽減することはできません。 スマードン氏は名前は明かさなかったが、あるハイパースケーラーでは故障率が高かったため、6,000台のサーバーを40PBを超えるメインメモリと交換する必要があったと述べた。 (したがって、AMD Epyc アーキテクチャがハイパースケーラーやクラウド ビルダーの間で市場シェアを侵食しているのも不思議ではありません。)

良いニュースは、DRAM の修正可能なエラー、電源とファンの障害、ネットワークとストレージの接続喪失とデバイスの障害はすべて高い確率で発生し、システム テレメトリを通じてクラッシュが近づいているという何らかの警告を提供することです。 。 また、多数のノードを含む仮想 NUMA クラスターでは、このような警告が発生した場合、クラッシュが発生する前にワークロードとデータをそのサーバーから隣接するマシンに移動する機会が得られます。 サーバーを修正または交換し、接続して HyperKernel に引き継がせると、動作が再開されます。

一言で言えば、これが、リリースされたばかりの TidalScale 4.1 の TidalGuard 機能の機能です。 ダウンタイムは費用がかかるため、回避することが重要です。 スマードン氏によると、企業の 85% は、ミッションクリティカルなシステムに対して少なくとも「フォーナイン」の可用性を確保する必要があり、これはシステムを冗長化し、複製することを意味します。 これは高価ではありますが、TidalScale が調査した企業の 3 分の 1 が、1 時間のダウンタイムで 100 万ドル以上のコストがかかると回答しており、さらに小規模な企業でさえ、システムがオフラインになると 1 時間あたり少なくとも 10 万ドルの損失が生じると述べていることを考えると、それだけの価値があります。

HyperKernel 上で TidalGuard を使用すると、システム修復の平均時間は約 10 分となり、他の方法と比べて 10 倍から 1,000 倍改善され、顧客はインフラストラクチャにさらに「2 9」の可用性を追加できます。

また、TidalGuard は、あまり話題になっていない、データセンターにおけるサーバーのウェアレベリングの問題にも取り組むことができます。

「タイヤをローテーションしなければならないことはご存知でしょう。また、フラッシュ メモリがウェア レベリングのバランスをとらなければ機能しないという事実は誰もがよく知っています」とスマードン氏は説明します。 「現在、サーバー (実際にはメイン メモリ) の消耗が加速し続けていますが、これを監視することはできませんでした。しかし、クラスター内でこれを監視することができ、使用状況の健全性に基づいて推定することができます。プール内でどのサーバーの寿命が最も残っているかを判断し、それらのサーバーでの使用を最初に優先します。」

この機能を使用すると、新しいフリートがいつ必要になるか、そしてそれがどれくらいの期間続くかを予測し始めることができます。

興味深いことに、企業が現在 TidalScale を導入している主な理由は信頼性、稼働時間、俊敏性であり、スケーラビリティとコスト削減は二の次の優先事項です。

ソフトウェア定義の NUMA クラスタリングが最終的に普及すれば、それはコンポーザブル インフラストラクチャ ツールボックスの重要なツールになる可能性があると考えられますが、TidalScale が買収ターゲットになる可能性があります。 そして、TidalScale がこの分野に登場してからどれだけ長く、そのテクノロジーが広範囲に展開されているという話は聞いたことがないことを考えると、TidalScale は、より広範囲での採用を推進するために、より大手の IT サプライヤーに採用されることを熱心に望んでいるのではないでしょうか。

Intel が Sapphire Rapids Xeon SP で一部のメモリ ビットを DRAM に戻していない場合、Intel はこの問題を解決するために TidalScale の買収に興味があるかもしれません。 しかしそれは、そもそもそれが問題を引き起こしたことを認めることを意味するので、その可能性は低いと思われます。

AMD がソケットを 1 つまたは 2 つ備えたマシンに限定していることを考えると、AMD は興味を持つかもしれません。 Arm グループも、自社のフリート用に個別の 4 ソケット サーバーと 8 ソケット サーバーを購入したくないクラウド サプライヤーの 1 つと同様に、仮想 NUMA サーバーを使用することもできます。 (アマゾン ウェブ サービスは社内で TidalScale を試しており、他のハイパースケーラーやクラウド ビルダーも同様に取り組んでいることは間違いありません。) サーバー仮想化に新たな角度を求めている VMware は興味を持つかもしれません。また、HPE、Dell、そしてレノボ。

今週のハイライト、分析、ストーリーを、何も挟むことなく直接あなたの受信箱にお送りします。今すぐ購読してください。