CISCO ACEの最初の部分であるアプリケーションバランシングでは、アプリケーションとネットワークリソースのバランシングの世界に少し突入しました。 このようなデバイスのファミリの特性、目的、および機能に精通しました。 主な実装シナリオと、バランサーの使用がもたらすメリットを検証しました。
最も可能性が高いのは、非常に高価であり、産業用バランサーが提供できる利点を理解していないと考える人が多いことです。 投稿では、私はこの瞬間に注意を払い、大多数がサービスを使用できることを示しようとします。
最初の部分では、同じデータセンターに直接配置されているアプリケーションのバランスをとる（サーバー間のバランスをとる）場合を検討しました。 あなたも言うことができる-1つのL2ドメインで。 記載されている利点に興味があり、このサービスを受けたいとします。 ユーザーは月に50〜100ドルでサーバーを提供する必要があるため、ほとんどの公共データセンターでは、このような機器はありません。 サーバーから企業のデータセンターに誰も入ることはできません（物理的な配置の瞬間だけでなく、既存の情報セキュリティポリシーも考慮されます）。
示された理由は一様ではありません。 プロジェクトが成長している場合、別のデータセンターに追加のサーバーを配置して、サービスの可用性を高めることをお勧めします。 また、情報レイディングの人気が高まっている場合、オプションも必要です。 このサービスは到達可能ですか？ はい、既存の機能を使用することもできます。
したがって、CISCO ACE（またはその他の適切なバランサー）が、直接接続されたサーバー間だけでなく、リモートリソース間でも負荷を分散できるという事実について詳しく見ていきましょう。 このモードは、ルーテッドワンアームモード（またはOn-a-Stick）と呼ばれます。
このモードのアーキテクチャには特別なものはありません。宛先NAT（ファームホストへ）の代わりに、バランサーは追加のソースNATを生成します。 さて、他のすべての機能をキャンセルした人はいません。 可能性を示す例を検討することを提案します。
この場合、すべてのトラフィックは仮想アドレス（VIP）に向けられます。 このアドレスは、バランサーに割り当てられます。 要求を処理し、リモートサーバーにリダイレクトします。 すべてのサーバーは、サーバーファームという1つの構造グループに含まれています。 少しセットアップしてみましょう。 多くの方法で、最初の記事で説明した構造を繰り返します。
1.サーバーを作成する
この場合、トポロジに示されたアドレスを持つ3つのサーバーがあります。
rserver host SERVER-1 description SERVER-1 ip address 1.1.1.1 inservice
rserver host SERVER-2 description SERVER-2 ip address 2.2.2.2 inservice
rserver host SERVER-3 description SERVER-3 ip address 3.3.3.3 inservice
rserver host SERVER-1 description SERVER-1 ip address 1.1.1.1 inservice
rserver host SERVER-2 description SERVER-2 ip address 2.2.2.2 inservice
rserver host SERVER-3 description SERVER-3 ip address 3.3.3.3 inservice
rserver host SERVER-1 description SERVER-1 ip address 1.1.1.1 inservice
rserver host SERVER-2 description SERVER-2 ip address 2.2.2.2 inservice
rserver host SERVER-3 description SERVER-3 ip address 3.3.3.3 inservice
rserver host SERVER-1 description SERVER-1 ip address 1.1.1.1 inservice
rserver host SERVER-2 description SERVER-2 ip address 2.2.2.2 inservice
rserver host SERVER-3 description SERVER-3 ip address 3.3.3.3 inservice
rserver host SERVER-1 description SERVER-1 ip address 1.1.1.1 inservice
rserver host SERVER-2 description SERVER-2 ip address 2.2.2.2 inservice
rserver host SERVER-3 description SERVER-3 ip address 3.3.3.3 inservice
2.サービスの可用性を判断するためのルールを説明します（WEBサーバーを設置します）
probe http HTTP_PROBE interval 5 passdetect interval 10 passdetect count 2 request method head url /index.html expect status 200 210 header User-Agent header-value "LoadBalance"
probe icmp ICMP_PROBE interval 10 passdetect interval 60 passdetect count 4 receive 1
probe http HTTP_PROBE interval 5 passdetect interval 10 passdetect count 2 request method head url /index.html expect status 200 210 header User-Agent header-value "LoadBalance"
probe icmp ICMP_PROBE interval 10 passdetect interval 60 passdetect count 4 receive 1
probe http HTTP_PROBE interval 5 passdetect interval 10 passdetect count 2 request method head url /index.html expect status 200 210 header User-Agent header-value "LoadBalance"
probe icmp ICMP_PROBE interval 10 passdetect interval 60 passdetect count 4 receive 1
パラメータと目的の説明- 最初の記事で説明します 。
3.デバイスをファームに接続します
serverfarm host FARM probe HTTP_PROBE probe ICMP_PROBE rserver SERVER-1 inservice rserver SERVER-2 inservice rserver SERVER-3 inservice
4.仮想アドレスを作成し、バランシングポリシーを記述します。
サーバーはバランサーから直接リクエストを受信するため、サーバーのクライアントアドレスは謎のままです。 何をすべきかを推測したら、X-Forwarded-Forヘッダーを追加します。
class-map match-all SERVER-VIP 2 match virtual-address 10.10.10.5 any
policy-map type loadbalance first-match LB-POLICY class class-default serverfarm FARM insert-http X-Forwarded-For header-value "%is"
class-map match-all SERVER-VIP 2 match virtual-address 10.10.10.5 any
policy-map type loadbalance first-match LB-POLICY class class-default serverfarm FARM insert-http X-Forwarded-For header-value "%is"
class-map match-all SERVER-VIP 2 match virtual-address 10.10.10.5 any
policy-map type loadbalance first-match LB-POLICY class class-default serverfarm FARM insert-http X-Forwarded-For header-value "%is"
ここでは、ファームファームとのバランスを取ることを示しました。
5.着信トラフィックを受信するインターフェースのポリシーを作成します
policy-map multi-match FARM-POLICY class SERVER-VIP loadbalance vip inservice loadbalance policy LB-POLICY loadbalance vip icmp-reply nat dynamic 10 vlan 100
ポリシーの最後の行に注意する必要があります。 バランサーに、送信者アドレス、つまり自分のアドレスを変換する方法を伝えます。
さて、インターフェイスの構成自体。 Interface Vlan 100とします。
interface vlan 100 ip address 10.10.10.10 255.255.255.0 service-policy input FARM-POLICY nat-pool 10 10.10.10.11 10.10.10.11 netmask 255.255.255.255 pat no shutdown
ip route 0.0.0.0 0.0.0.0 10.10.10.1
interface vlan 100 ip address 10.10.10.10 255.255.255.0 service-policy input FARM-POLICY nat-pool 10 10.10.10.11 10.10.10.11 netmask 255.255.255.255 pat no shutdown
ip route 0.0.0.0 0.0.0.0 10.10.10.1
6.結果として何が得られますか？
6.1。 DNSに記録：domain.org IN A 10.10.10.5。
6.2。 クライアントはリクエストをバランサーに送信します。
6.3。 バランサーはアクティブなサーバー間で要求を分散し、宛先アドレスを実サーバーアドレスに変更し、ソースアドレスを構成で指定されたアドレス（10.10.10.11）に変更します。
6.4。 サーバーは10.10.10.11からすべてのリクエストを受信しますが、X-Forwarded-Forヘッダーがあります。 サーバーをバランサーに応答します。
6.5。 バランサーは、受信した応答をリソースのクライアントに返します。
クライアント側では、サーバーアドレスのリストを提供し、DNSレコードを変更する必要があります。 当然、機能しているサーバーの数は増減します。 一般に、機能は影響を受けません。
この機能には、有利に使用できる興味深い機能が1つあります。
ACEに1つのインターフェイスがある場合を検討しました。 2つのインターフェイスオプションを見てみましょう。 さらに、1つのインターフェイスは1つのプロバイダーに接続され、2番目のインターフェイスは別のプロバイダーに接続されます。 または、独自のAS、2、3のプレフィックス、2つのプロバイダーへの接続（以下に非常に多くの条件がある理由を理解します）があり、トラフィックが1つのプロバイダーを介して1つのサブネットに流れ、別のプロバイダーを介して別のサブネットに流れるようにすることができます。 （BGPトラフィック制御のいくつかの興味深い側面については、 BGPで説明しています 。 トラフィック動作のいくつかの機能 ）。
そのような状況で何が起こるか見てみましょう。
1.クライアントは仮想アドレスにアクセスします（DNSのレコードのおかげ）。
2.トラフィックはプロバイダー1を通過し、そのチャネルをロードします。
3.プロバイダーNo. 1からバランサーに向かう途中で、トラフィックを「クリア」できます。 行動分析とシグネチャ分析のおかげで、DDoSとあらゆる種類のスキャン/侵入が遮断されます。
4.バランサーはプロバイダー番号2を使用してサーバーにリクエストを送信します。 そのチャネル（ISP-2）は、DDoSによってアンロードされたままです。
5.サーバーは正当な要求のみを処理し、応答をバランサーに送信してから、クライアントに返します。
当然、このスキームはDDoS保護装置（Arbor Peakflow、CISCO Detector / Guard）の可用性を提供します。 また、良いIPSは傷つきません。
オンデマンドのDDoSに対するこのような保護。 必要に応じて、または継続的に、クライアントはDNSを変更するだけです。
スキームを実装するには、小さな追加のバランサー設定を行う必要があります。 攻撃が発生すると、プロバイダー番号1のチャネルがロードされます。 プロバイダー番号2のチャネルは「クリーン」のままです。 トラフィック管理の微妙さと機能は別の問題です。アイデアは、これをどのように実装できるかを示すことでした。
頑張って！