ダイレクトサーバーリターンを使用したHTTPリクエストの転送
サーバーが複数のデータセンターに分散していて、それぞれが異なるファイルを保存しています。ユーザーが単一のドメインを介してすべてのサーバー上のファイルにアクセスできるようにし、個々のサーバーがファイルをユーザーに直接返すようにしたい。
以下に簡単な例を示します。1）ユーザーのブラウザリクエスト http://www.example.com/files/file1.Zip 2）リクエストはDNSAレコードに基づいてサーバーAに送信されます。 example.com。 3）サーバーAはリクエストを分析し、/ files/file1.ZipがサーバーBに保存されていることを確認します。4）サーバーAはリクエストをサーバーBに転送します。5）サーバーBはサーバーを経由せずにfile1.Zipをユーザーに直接返します。 A。
注：手順4と5はユーザーに対して透過的である必要があり、単一ドメインの要件に違反するため、ユーザーにリダイレクトを送信する必要はありません。
私の調査によると、私が達成したいのは「ダイレクトサーバーリターン」と呼ばれ、負荷分散の一般的な設定です。ハーフリバースプロキシと呼ばれることもあります。
ステップ4では、MACアドレス変換を実行してから、要求をネットワークに戻し、サーバーのネットワーク外のサーバーの場合はトンネリングが必要になるようです。
手順5では、負荷分散設定の実サーバーに従って、サーバーBを構成する必要があります。つまり、サーバーBはループバックインターフェイスにサーバーAのIPアドレスを持っている必要があり、そのIPアドレスに対するARP要求に応答してはなりません。
私の問題は、実際にステップ4をどのように達成するかです。
レイヤー4での単純な負荷分散のためにこれを実行できるハードウェアとソフトウェアをたくさん見つけましたが、これらのソリューションは不十分であり、必要な種類のカスタムルーティングを処理できません。自分で解決策を練る必要があるようです。
理想的には、Webサーバーレベル、つまりPHPまたはC＃/ ASP.net）でルーティング/転送を実行したいと思います。ただし、次のような下位レベルで実行することもできます。 ApacheまたはIIS、あるいはさらに低いレベル、つまりすべての前にあるカスタムプロキシサービス。
ありがとう。
ダニエル-おそらく、LVSとクラスター化されたファイルシステムでこれを比較的簡単に行うことができます。 LVSロードバランサーはHTTPリクエストを受信し、リクエストに応答できるWebノードにリクエストを転送します。応答はWebノードから直接送信され、ロードバランサーは応答にまったく関与しません。
仮想化されたXenインスタンスでうまく機能する このガイド （Fedora上）をまとめました。
アプリケーションリクエストのルーティングはどうですか？
http://www.iis.net/download/ApplicationRequestRouting
バックエンドストレージサーバーはDFSを使用して、コンテンツの同期をバックで維持できます。これにより、コンテンツにアクセスするサーバーが常にコンテンツへの最短ルートをたどることが保証されます。
目標を達成するには、キャッシュプロキシサーバーまたはHTTPリダイレクトのいずれかを使用する必要があると思います。
たとえば、nginxでは、バックエンド（PHPスクリプトまたはFastCGIでホストされているサーバー）を使用して、移動する「データセンター」を決定し、X-Accelを返します-そのデータセンターへのproxy_passを使用して新しい場所にリダイレクトします。この後、nginxは結果をキャッシュ/保存する必要があります。
したがって、すべてのデータセンターでの構成は、100％ローカルのファイルでのみ異なります。
2番目のケース-バックエンドは、必要な直接リンクを含む301エラーコードを返します。
ダニエル、あなたは本当に宿題をしました。たぶん、私が間違っていることを証明する教祖がそこにいるのかもしれませんが、私の最初の応答は「それをしないでください」です。私はそれが一種の無回答であることを知っていますが、なぜあなたが本当にこれを必要とするのかについての理由なしに、それは私が持っている最良の答えです。提案されたソリューションは機能すると思いますが、ドメインを非表示にするためだけに処理するには多くの構成とセットアップが必要です。私には、脆弱すぎて複雑に思えます。
私はどちらかを提案します：
- 交渉のハードボールをプレイし、その単一ドメインの要件を離れて交渉します。これがどれだけ複雑さとコストを増加させるかを本当に説明してください。次に、各サーバー/サイトへのプレーンHTTPリダイレクトを使用します。
- [〜＃〜]または[〜＃〜]
- 冗長性を確保するために、すべてのデータをすべてのデータセンター（DC）に複製します。 Anycast を使用して、1つのドメインを複数のDCで使用できるようにします。各DCで選択した従来のロードバランサーを使用します。
HTH
ダニエル、
この回避策は、アプリケーション層で行う必要があります。下位層でそれを行うと、ルールはすべてのトラフィックに適用されるようになりますが、ここでは、特定のアプリケーションに適用されます。
サブドメインを作成し、さまざまなサーバーのIPアドレスをサブドメインのAレコードとして指定することをお勧めします。したがって、同じドメイン内にあるため、サードパーティの取引が処理されます。次に、中央サーバーのデータベースを使用して、特定のサーバーにCURLリクエストを送信します。そうすれば、アプリケーションが動作している間、ドメインも非表示になります。ただし、ここでの唯一の問題は、データベースが常にスペックレスである必要があることです。そうしないと、アプリケーションが惨めに失敗します。
データベースが常に効率的に実行されていることを確認してください。サーバーのダウンタイムの落とし穴を経験する必要がないように、バックアップデータバンクの作成を検討する必要があります。
よろしく
Binaek Sarkar
財団
Arp manglingやその他のトリックを介してDSRを実行すると、ローカルレベルで機能します。これを大量のデータセンターに拡張したい場合は、「スレーブ」データセンターと呼びましょう。パケットをカプセル化して、次の別のボックスに送信する必要があります。リモートDCカプセル化を削除する-ノードを個別に指定することも、通常のarpベースのDSRを実行するロードバランサーの別のインスタンスにすることもできます。
複数のDCでこれを行う場合は、フィルタリングによって、管理されていないIPアドレスからの発信トラフィックが許可され、フローベースの可能性がある方法でファイアウォールデバイスが許可されないようにする必要もあります。干渉します-会話の片側しか表示されないため（反対側はカプセル化されています）
ただの追加-なぜこの特定のセットアップが必要なのかについての洞察を提供できますか？リダイレクトや複数のドメイン名を使用するのではなく、これを行うことで正確に何を達成しようとしていますか。実際のリソースファイルに対して複数のドメイン名で問題がない場合（CDNまたはエニーキャストソリューションの方がはるかに経済的で信頼性の高いソリューションです）、アプリロジックでユーザーをリダイレクトするリソースを決定します。
あなたが提案していることは技術的に興味深いものですが、単一障害点も生み出しています-arpスプーフィングを使用してローカルのレイヤー2レベルでこれを理解するのが難しい場合、グローバルレベルでの処理は次のようになりますより複雑な.... CDNはおそらく必要なものです。
とは言うものの、純粋にネットワークの観点からすると、これは本当に興味深いことです。もう少し詳細を提供できれば、Linuxツールを使用して特定のソリューションを考え出すことができます。
「同じドメイン」の要件を削除できず、高度なネットワークルートに移動したくない場合は、「異なる場所に異なるファイルを保存する」要件を削除できますか？
すべてのサーバー（場所）にすべてのファイルを格納できる場合は、単一ドメインの背後にあるラウンドロビンIPの背後に同じように構成されたスタックを持つことができます。すべての場所は、単一のドメインの背後で完全に機能し、到達可能です。もちろん、データベースアクションには、レプリケーションまたはリモート接続の要件があります。
高速で低遅延のLANを介したリバースプロキシはそれほど悪くないため、サーバーと場所を区別します（Yorikの回答を参照）。
商用ロードバランサーは、ダイレクトサーバーリターン用に構成できます。 （F5 BIG-IPはそれを行うことができます。それらの用語では、「nPathルーティング」と呼ばれます。）低コストのソリューションはLinux VirtualServerです。直接ルーティングの設定は文書化されています ここ 。
ただし、負荷分散をレイヤー3に対して透過的にするには、転送をレイヤー2で実行する必要があります。つまり、ロードバランサーとコンテンツサーバーが同じ物理セグメント上にある必要があります。いくつかのデータセンターでそれをどのように達成するかはわかりません。
または、Flashアプリケーションを含むページをHTTPリダイレクトします。次に、それぞれが同一生成元の原則を満たす独立したサイトができます。
Linux Virtual Serverとkeepalivedの組み合わせ、そしておそらくいくつかのarptableマジックは、あなたが求めていることを達成するはずです。私は過去にその方法を広範囲に使用しましたが、非常にスケーラブルであることが証明されています。接続を受信した後、実サーバーがクライアントと通信するという事実により、ロードバランサー（LVS +キープアライブ）は非常にスケーラブルになります。
秘訣は、arptablesを正しくすることです。 Red Hat/CentOSでは、パッケージはarptables_jfと呼ばれます。 10.10.0.1があなたVIPで、10.10.0.10がサーバーBのIPであると仮定して、例からサーバーBに配置するいくつかのサンプルルールを次に示します。
arptables -A IN -d 10.10.0.1 -j DROP
arptables -A OUT -s 10.10.0.1 -j mangle --mangle-ip-s 10.10.0.10
ロードバランサー（サーバーA）と実サーバー（サーバーB +）は同じネットワーク上にある必要があることに注意してください。
また、VIPのIPを使用した「ダミー」インターフェイスを使用して各実サーバーを構成する必要があります。繰り返しますが、Red Hat/CentOSでは：
# cat /etc/sysconfig/network-scripts/ifcfg-dummy0
DEVICE=dummy0
BOOTPROTO=static
IPADDR=10.10.0.1
NETMASK=255.255.255.255
ONBOOT=yes
TYPE=Ethernet
Arptableルールは、そのIPに対するARP要求のサイレンシングを処理します（arptableがない場合、すべての実サーバーとロードバランサーが10.10.0.1を持っているという質問に答えます）。
これがお役に立てば幸いです。