Mini ITX クラスター Turing Pi 2 (32 GB RAM 搭載)

Habr コミュニティへようこそ! 私は最近、最初のバージョンのクラスターボードについて書きました [V1]。 そして今日は、私たちがこのバージョンにどのように取り組んだかをお話ししたいと思います Turing V2 (32 GB) ランダム・アクセス・メモリ。

私たちは、ローカル開発とローカル ホスティングの両方に使用できるミニサーバーに熱心に取り組んでいます。 デスクトップ コンピュータやラップトップとは異なり、当社のサーバーは 24 時間年中無休で動作するように設計されており、フェデレーションにすぐに接続できます。たとえば、クラスタ内に 7 つのプロセッサがあったが、4 分後には 5 のプロセッサになりました (追加のネットワーク機器なし)。これらすべてがコンパクトなフォームファクターに収められており、静かでエネルギー効率が高いです。

当社のサーバーのアーキテクチャは、クラスター構築の原則に基づいています。 複数の演算モジュール（プロセッサ）をボード上のイーサネットネットワークで接続するクラスタボードを作成します。 話を単純化するために、私たちはまだ独自の計算モジュールを作成していませんが、Raspberry Pi 計算モジュールを使用しており、新しい CM4 モジュールを本当に期待していました。 しかし、新しいフォームファクターではすべてが計画に反しており、多くの人が失望していると思います。

以下は、V1 から V2 にどのように移行したか、そして Raspberry Pi CM4 の新しいフォーム ファクターにどのように対応しなければならなかったのかを示しています。

したがって、7 つのノードを含むクラスターを作成した後、次の疑問が生じます。 製品の価値を高めるにはどうすればよいでしょうか？ 8、10、または 16 ノード? モジュールのメーカーはどこですか? 製品全体について考えると、ここで重要なのはノードの数やメーカーではなく、構成要素としてのクラスターの本質そのものであることがわかりました。 最小限の構成要素を探す必要があります。

最初のはクラスターとなり、同時にディスクと拡張カードを接続する機能を持ちます。 クラスタ ユニットは、幅広い拡張機能を備えた自立したベース ノードである必要があります。

2番目の、より大きなクラスターを構築することで最小限のクラスター ブロックを相互に接続できるようになり、これが予算とスケーリング速度の点で効果的になります。 スケーリング速度は、通常のコンピュータをネットワークに接続するよりも速く、サーバー機器よりもはるかに安価である必要があります。

第3、最小限のクラスタ ユニットは、非常にコンパクトで、モバイル性があり、エネルギー効率が高く、費用対効果が高く、動作条件に厳しいものでなければなりません。 これは、サーバー ラックやそれに接続されるあらゆるものとの主な違いの XNUMX つです。

まずはノード数を決定することから始めました。

ノード数

単純な論理的判断により、最小限のクラスター ブロックには 4 つのノードが最適なオプションであることがわかりました。 1 ノードはクラスターではありません。2 ノードでは不十分です (1 マスター 1 ワーカー、ブロック内でスケーリングの可能性はありません。特に異種オプションの場合)。3 ノードは問題ないように見えますが、2 のべき乗の倍数ではなく、範囲内でスケーリングできません。ブロックには制限があり、6 ノードの価格は 7 ノードとほぼ同じです (私たちの経験から、これはすでに高コストです)、8 ノードは多く、mini ITX フォーム ファクターには適合せず、PoC 向けのソリューションはさらに高価です。

ブロックごとに XNUMX つのノードが黄金の平均であると考えます。

• クラスターボードあたりの材料が少なくなるため、生産コストが安くなります
• 4 で割り切れる場合、4 つのブロックだけで 16 個の物理プロセッサが得られます
• 安定したスキーム 1 マスターと 3 ワーカー
• より多くの異種バリエーション、汎用コンピューティング + アクセラレーション コンピューティング モジュール
• SSD ドライブと拡張カードを備えた mini ITX フォームファクター

コンピューティングモジュール

4 番目のバージョンは CMXNUMX に基づいており、SODIMM フォーム ファクターでリリースされると考えられていました。 しかし…
ユーザーが CM4 について意識しないように、SODIMM ドーターボードを作成し、CM4 を直接モジュールに組み込むことにしました。

Raspberry Pi CM4 をサポートする Turing Pi コンピューティング モジュール

一般に、モジュールを求めて、128 MB RAM から 8 GB RAM を搭載した小型モジュールに至るまで、コンピューティング モジュールの市場全体が開かれました。 16 GB 以上の RAM を搭載したモジュールが先行しています。 クラウド ネイティブ テクノロジーに基づくエッジ ホスティング アプリケーションの場合、1 GB RAM ではもはや十分ではなく、最近では 2 GB、4 GB、さらには 8 GB RAM を搭載したモジュールが登場しており、成長の余地が十分にあります。 機械学習アプリケーション用にFPGAモジュールを使用するオプションも検討しましたが、ソフトウェアエコシステムが開発されていないため、サポートは延期されました。 モジュール市場を調査しているときに、モジュール用のユニバーサル インターフェイスを作成するというアイデアを思いつき、V2 ではコンピューティング モジュールのインターフェイスの統一を開始しています。 これにより、バージョン V2 の所有者は、他のメーカーのモジュールを接続し、特定のタスク用にそれらを混合できるようになります。

V2 は、Lite バージョンや 4 GB RAM を搭載したモジュールを含む、Raspberry Pi 4 Compute Module (CM8) の全製品ラインをサポートします。

ペリフェリー

モジュールのベンダーとノード数を決定した後、周辺機器が配置されている PCI バスに取り組みました。 PCI バスは周辺機器の標準であり、ほぼすべてのコンピューティング モジュールに搭載されています。 複数のノードがあり、理想的には、各ノードが競合リクエスト モードで PCI デバイスを共有できます。 たとえば、これがバスに接続されたディスクの場合、すべてのノードで使用できます。 マルチホストをサポートする PCI スイッチを探し始めましたが、どれも要件を満たしていないことがわかりました。 これらすべてのソリューションは主に 1 つのホストまたは複数ホストに限定されていましたが、エンドポイントへの同時リクエストのモードはありませんでした。 50 番目の問題は、チップあたり 2 ドル以上というコストの高さです。 V2 では、PCI スイッチを使用した実験を延期することを決定し (開発中に後で戻ります)、各ノードに役割を割り当てる方法を採用しました。最初の 6 つのノードはノードごとに mini PCI Express ポートを公開し、XNUMX 番目のノードは公開します。 XNUMX ポート XNUMX Gbps SATA コントローラー。 他のノードからディスクにアクセスするには、クラスター内のネットワーク ファイル システムを使用できます。 なぜだめですか？

スニークピーク

私たちは、議論と考察を通じて、最小クラスター ブロックが時間の経過とともにどのように進化したかを示すいくつかのスケッチを共有することにしました。

その結果、4 つの 260 ピン ノード、2 つの mini PCIe (Gen 2) ポート、2 つの SATA (Gen 3) ポートを備えたクラスター ユニットが完成しました。 このボードには、VLAN をサポートするレイヤー 2 マネージド スイッチが搭載されています。 最初のノードにはミニ PCIe ポートがあり、そこにネットワーク カードを取り付けて別のイーサネット ポートまたは 5G モデムを取得し、最初のノードをクラスタ上のネットワークおよびイーサネット ポート用のルーターに変えることができます。

クラスター バスには、すべてのスロットを介してモジュールを直接フラッシュする機能や、もちろん各ノードの速度制御付き FAN コネクタなど、より多くの機能があります。

アプリケーション

セルフホスト型アプリケーションとサービスのためのエッジ インフラストラクチャ

V2 は、消費者/商用グレードのエッジ インフラストラクチャの最小限の構成要素として使用することを目的として設計されました。 V2 を使用すると、安価に概念実証を開始し、成長に合わせて拡張し、エッジでホストすることがより経済的かつ現実的に合理的なアプリケーションを徐々に移行します。 クラスター ブロックを相互に接続して、より大きなクラスターを構築できます。 これは、確立するための特別なリスクを伴うことなく、段階的に行うことができます。
プロセス。 現在、ビジネス向けのアプリケーションが膨大にありますが、 ローカルでホストできる.

ARMワークステーション

クラスターあたり最大 32 GB の RAM を搭載しており、最初のノードはデスクトップ バージョンの OS (Ubuntu Desktop 20.04 LTS など) に使用でき、残りの 3 ノードはコンパイル、テスト、デバッグ タスク、およびクラウド ネイティブの開発に使用できます。 ARM クラスター用のソリューション。 本番環境の ARM 周辺インフラストラクチャ上の CI/CD のノードとして。

CM2 モジュールを備えた Turing V4 クラスターは、AWS Graviton インスタンスに基づくクラスターとアーキテクチャがほぼ同じです (違いは ARMv8 のマイナー バージョンにあります)。 CM4 モジュール プロセッサは ARMv8 アーキテクチャを使用しており、x1 インスタンスよりもはるかに安価であることが知られている AWS Graviton 2 および 86 インスタンスのイメージとアプリケーションを収集できます。

出所： habr.com