Linux を実行している x86-64 コンピューターを持っていますが、これを他の非 x86-64 Linux マシンで補いたいと考えています。
同じアーキテクチャーでなくても、別のマシンの計算能力を何らかの形で活用することは可能ですか?
2 番目の質問として、どのようなパフォーマンスの向上が利用可能で、それを機能させるには専用のソフトウェアが必要ですか? それとも、Linux はクラスター/追加のマシンを追加の CPU として抽象化できますか?
Linux を実行している x86-64 コンピューターを持っていますが、これを他の非 x86-64 Linux マシンで補いたいと考えています。
同じアーキテクチャーでなくても、別のマシンの計算能力を何らかの形で活用することは可能ですか?
2 番目の質問として、どのようなパフォーマンスの向上が利用可能で、それを機能させるには専用のソフトウェアが必要ですか? それとも、Linux はクラスター/追加のマシンを追加の CPU として抽象化できますか?
ソフトウェアによっては、抽象化できる場合とできない場合があります。このようなことを行うには、通常、リモート プロシージャ コールが必要であり、使用するライブラリによっては、抽象化できる場合とできない場合があります。
基本的な例は、RPC を実行し、引数として整数を与えることです。ビッグ エンディアンを使用するアーキテクチャもあれば、リトル エンディアンを使用するアーキテクチャもあり、RPC ライブラリはそれを処理する必要があります。
とにかく、この事実に頼るべきではありません。適切な抽象化レイヤーが必要です(たとえば、IP を介した通信は出発点として適しています)。これは、「サービス中のアップグレード」を可能にするために必要です。つまり、開始クラスタ構成と同じアーキテクチャである場合もそうでない場合もある新しいマシンを追加します。
上司のところに行くことを想像してみてください。 (そして、返事がはっきりと聞こえます)
もちろん、特定のケースで本番環境の問題が範囲外である場合は、私の引用を無視してかまいません. これは、大規模な展開の典型的な要件であるとだけ言っておきましょう。
最後に、対称クラスターを扱う方が常に簡単ですが (メンテナンスが簡素化されます)、非対称クラスターは「ローリング アップグレード」を扱う場合の「足がかり」になる可能性があります。
明確化: 私は、すべてを抽象化することを決して避けませんでした。 明確化#2:「アーキテクチャ」によって、「システム全体のアーキテクチャ」ではなく、「CPUアーキテクチャ」を想定しています。
質問の 2 番目の部分については、すべてソフトウェアのアーキテクチャに依存します。