nservicebus - NService Bus: デプロイに関する重要な問題

Question

スケールアウトされたパブリッシャー (DB サブスクリプション ストレージを使用) からの複数のパブリケーションと、スケールアウトされたサブスクライバー (ディストリビューターを使用) による複数のサブスクリプションのコンテキストで、次の質問を検討してください。自動化された MSI を使用して、初期展開、アップグレードなどのためにインストールとアンインストールが定期的に行われます。 .

1. DB サブスクリプション ストレージを使用している場合、DB がダウンした場合はどうなりますか? メッセージを公開するためにサブスクリプション DB へのアクセスが必要な場合、メッセージはどのように配信されますか? それは失われますか？Bus.Publish の呼び出しは例外をスローしますか?
2. ダウンタイムの展開が必要ないと仮定すると、特定のパブリケーションのサブスクリプション DB を別のサーバーに移動したい場合はどうなるでしょうか? このような移行をどのように管理しますか?
3. サブスクライバー側のディストリビューターについても同じ質問があります。ディストリビューター エンドポイントを移動したい場合はどうすればよいでしょうか? 考えられるシナリオの 1 つは、単一のディストリビューター マシンを使用する複数のサブスクリプションがある場合、それらの一部を別のディストリビューター サーバーに移動して負荷を軽減するのが難しい場合です。
4. このようなセットアップの場合、インストール/アンインストールのシナリオはどのようになりますか (最初のアップグレードと継続的なアップグレードの両方)? 「論理パブリケーション」とサブスクリプション DB の展開、および「論理サブスクリプション」とディストリビュータ用の特別なインストール/アンインストール スクリプトが必要なようです。パブリッシャー インスタンスには、特別なインストール/アンインストール ロジックは必要ありません (構成されたサブスクリプション DB を使用してメッセージのパブリッシュを開始し、アンインストールされると停止するため)。サブスクライバー ワーカー ノードは、ディストリビューター エンドポイントの正しい構成以外に、インストール時に特別なことは必要ありませんが、ワーカー ノードのディストリビューター リストから確実に削除されるように、アンインストール ロジックが必要です。

Answer 1

1. 最終的に、パブリッシャーは失敗し、メッセージは内部キューに蓄積されます。メッセージサイズとDBが起動するのを待つ時間に基づいて、これを処理するために必要なディスクのサイズを計画する必要があります。そこから、処理できるダウンタイムの量に基づいています。DBミラーリングまたはクラスタリングを使用して、DBのダウンタイムを減らすことができます。
2. ミラーリングおよびクラスタリングテクノロジーもこれに役立ちます。手動フェイルオーバーを実行するか自動フェイルオーバーを実行するか、およびどこで実行するか（リモートサイト？）によって異なります。
3. ここでは、MSMQのクラスタリングが役立ちます。ディストリビューターを削除してクラスター内に移動したい場合は、問題ありません。もう1つの可能性は、HTTPを介してディストリビューターを公開し、ソフトウェアまたはハードウェアの負荷分散ソリューションの背後でそれらを負荷分散することです。ロードバランサーの背後では、物事をより自由に移動できます。
4. あなたはすでにこれをよく理解しているようですね:)

Answer 2

サブスクリプション DB の高可用性に関する最初の質問に対して、フェールオーバーにクラスターを使用できます。DB がダウンしている場合、Bus.Publish は例外をスローします。アプリのアップグレード時にサブスクリプション DB を停止する必要がないように、アプリケーション DB とは別にサブスクリプション DB を保持することをお勧めします。これは別の DB サーバーである必要はありません。同じ DB サーバー上の別の DB で問題ありません。

サーバーの移動については、通常、DNS レベルで管理されます。この場合、通信が移動するまで、両方を一定期間実行する必要があります。

ディストリビューターに関する 3 番目の質問について - 異なるパブリッシャーまたはサブスクライバー間でディストリビューターを共有しないでください。

経験則として、この種の保守作業を行う場合は、サブスクライバーを追加/削除しないことをお勧めします。これにより、通常はかなり単純化されます。