9

通常、Azure ワーカーへのアクセスは、サービス定義で定義されているエンドポイントを介して行われます。これらのエンドポイント (TCP または HTTP(S) である必要があります) は、ロード バランサーを通過した後、Azure マシンの実際の IP/ポートに接続されます。

私のアプリケーションは UDP を使用することで劇的なメリットが得られます。請求のためにバイトがカウントされるセルラー デバイスから接続しており、SYN/ACK/FIN のオーバーヘッドが送信している 8 バイトのパケットを小さくするからです。データを直接 ICMP メッセージ ヘッダーに入れることも考えました。ただし、これはいずれもロード バランサーによってサポートされていません。

Azure 仮想マシンで ping を有効にしてから ping を実行できることは知っています -- http://weblogs.thinktecture.com/cweyer/2010/12/enabling-ping-aka-icmp-on-windows-azure-roles.html .

Azure VM アドレスの IP アドレスとポートを単純に配布し、アプリケーションがそのワーカーと直接通信する TCP ベースのサービス (ロード バランサーを介して公開) の使用を妨げているものはありますか? (自分で負荷分散を処理する必要があります。) ワーカーがシャットダウンまたは移動した場合、アプリケーションは十分に賢く、TCP エンドポイントに再接続し、データを送信する新しい場所を要求します。

このコンセプトは機能しますか、それとも、この種の直接アクセスを防ぐための何かが用意されていますか?

4

2 に答える 2

3

入力 (外部) エンドポイントを公開する独自のルーターを実行し、同じロールまたは別のロールでサービスの内部エンドポイントにルーティングする必要があります (これが実際のリモート デスクトップのしくみです)。選択によって特定のインスタンスに直接接続することはできません。

Benjamin Guinebertière による 2 部構成のブログ シリーズがあり、スティッキー セッションを提供する IIS アプリケーション リクエスト ルーティングについて説明しています (パート 1、パート 2 )。これは良い出発点かもしれません。

Ryan Dunn は、Cloud Cover Show で http セッション ルーティングについても話し、フォローアップのブログ投稿も行いました。

これらの 2 つの例は、http をルーティングしているため、実際に行っていることとは異なりますが、同様の前提を共有しています。

于 2011-04-18T13:29:16.713 に答える
1

特定の VM インスタンスのローカル ポートに送信されるパブリック IP のポートを定義するために使用できる InstanceInputEndpoint というものがあります。したがって、特定の VM に直接アクセスできる特定のポートと IP の組み合わせができます。

  <InstanceInputEndpoint name="HttpInstanceEndpoint" protocol="tcp" localPort="80">
    <AllocatePublicPortFrom>
      <FixedPortRange max="8089" min="8081" />
    </AllocatePublicPortFrom>
  </InstanceInputEndpoint>

詳細: http://msdn.microsoft.com/en-us/library/windowsazure/gg557552.aspx

于 2013-11-20T16:44:18.773 に答える