Nexusアーティファクトリポジトリの負荷分散

Nexusの負荷分散は現在、Sonatypeではサポートされていません。ただし、Nexusインスタンスを2つ目の前に配置して、スマートプロキシを有効にするか、新しい機能を使用する場合を除きます。

それでも、ファイルシステムをのGlusterFSと共有し、Apacheロードバランサー構成とUIのネクサス構成でスティッキー/storageを有効にしようと試みました。

UIでは、NexusコンテナーがCookie値を設定するためのプロパティを尊重していないように見えるので、惨めに失敗しています。現在、次の構成を使用しています。

ストレージの場合、制限GETとHEADリクエストのみで機能するようですが、それでもPOSTsを開く必要があります。スケジュールされたジョブの付随的な影響についても確信が持てなかったため、「セカンダリ」ノードではすべて無効にされました。

誰かが負荷分散ネクサスの信頼できる構成をある程度達成しましたか？UIは実際には負荷分散されることは重要ではありません。ストレージについては十分満足しています。

SonatypeのNexus 3 Pro は、コンポーネントファブリックと総称される2つのメカニズムを通じて高可用性をサポートしています。

• ピアツーピアのリポジトリマネージャーとは、単一障害点とも呼ばれるマスターが1つ存在しないことを意味します。パッケージはノード間で複製され、最終的に整合性が保たれます。
• ストレージバックエンドは、S3などの耐久性の高いストレージを使用できることを意味します。
• 動的ノードを使用すると、自動スケーリングのサポートにより、需要が高いときに容量を増やし、需要が低いときに容量を減らしてコストを削減できます。

コミュニティ製品のHAをサポートすることは、Sonatypeの利益にはなりません。有料の製品から一部の企業顧客を共食いするためです。