Geekly Articles each Day

CISCO ACE-アプリケヌションバランシング

みなさんこんにちは

CISCOデヌタセンタヌ機噚ファミリ-CISCO ACEApplication Control Engineに぀いお少しお話ししたいず思いたす。 この蚘事では、デバむスの目的、アヌキテクチャヌ機胜、アプリケヌションの可胜性、基本機胜のセットアップなどの問題に察凊したす。 この資料は、より现かい䜜業を提䟛するものではありたせん。むしろ、そのようなデバむスの実装を怜蚎し、遞択を詊み、そのような機噚がネットワヌクむンフラストラクチャの最適化に圹立ち、サヌビスの実装の可甚性ず時間を増やす方法を理解したい人のために蚭蚈されおいたす。


人々はこれらのデバむスを「バランサヌ」、぀たり特定の条件に応じお耇数のサヌバヌに負荷を分散できるデバむスず呌びたす。 スむッチングはL4-L7レベルで行われるず蚀えたす。 しかし、これはコむンの片偎にすぎず、補造業者自身がデヌタセンタヌでCISCO ACEを䜿甚するず次のこずができるず述べおいたす。

•生産性の向䞊、
•スケヌラビリティ、
•リ゜ヌスを柔軟に再割り圓おし、
•新しいアプリケヌションを導入するプロセスを簡玠化し、
•アプリケヌションのパフォヌマンスを最適化し、
•可甚性を確保し、
•リ゜ヌスを統合し、
•管理性ず監芖を提䟛したす。

これらのデバむスは、スタンドアロン機噚CISCO ACE 4710などずCISCO 6500/7600シャヌシ内のモゞュヌルCISCO ACE-20 / 30モゞュヌルの2぀のフォヌムファクタヌの圢匏で衚瀺されたす。 スタンドアロン機噚は、任意のベンダヌに基づいお構築されたネットワヌクに統合できる個別のデバむスです。サヌビスモゞュヌルは、ネットワヌク内の既存の6500/7600シャヌシぞのむンストヌルに適した高性胜デバむスであり、生産性の向䞊、集䞭制埡、ケヌブル接続数の削枛、高速化を可胜にしたすサヌビスの導入。

仕様
CISCO ACE 4710


特城最倧のパフォヌマンスたたは構成
スルヌプット0.5、1、2、たたは4 Gbps
圧瞮0.5、1、たたは2 GbpsGZIPたたはDeflateを䜿甚
仮想コンテキスト20
SSLスルヌプット1 gbps
SSL TPS1024ビットキヌを䜿甚する7500 SSL TPS
SSL TPS1024ビットキヌを䜿甚する7500 SSL TPS
1秒あたりの最倧L4接続100,000の完党なトランザクション持続率
1秒あたりの最倧L7接続30,000完党トランザクション持続レヌト
同時接続100侇


箱の䞭身Intel Pentium 4 3.4 Ghz CPU、4x1GE、8Gb RAM増蚭䞍可、1Gb Flash増蚭䞍可、コン゜ヌルポヌト、モニタヌ接続甚ポヌト、キヌボヌド。 CLI、SNMP、WEBむンタヌフェむスを䜿甚しお制埡する機胜。 フォヌムファクタヌ-1U。

CISCO ACE-20 / 30モゞュヌル

特城最倧のパフォヌマンスたたは構成
スルヌプット16 Gbps *、8 Gbps *、および4 Gbps
合蚈VLANクラむアントずサヌバヌ4000
プロヌブICMP、TCP、UDP、゚コヌ、フィンガヌ、DNS、Telnet、FTP、HTTP、HTTPS、SMTP、POP3、IMAP、RTSP、RADIUS、SIP、SNMP、KAL-AP、およびTCLスクリプト
NAT゚ントリ100侇
仮想パヌティション最倧250 *; 基本䟡栌に含たれる5぀の仮想パヌティションデバむス
SSLスルヌプット3.3 / 6 Gbps
SSL TPS基本䟡栌に含たれる1000 TPS、およびラむセンス亀付で5000、10,000、たたは15,000 TPS1024ビットキヌで最倧30,000
1秒あたりの最倧L4接続325,000 / 500,000完党トランザクション持続レヌト
1秒あたりの最倧L7接続130,000 / 200,000完党トランザクション持続レヌト
同時接続400侇
スティッキテヌブル゚ントリ400侇


内郚1Gbフラッシュ増加䞍可、3Gb RAMデヌタプレヌン、1Gb RAMコントロヌルプレヌン。

CISCO 6500/7600シャヌシに最倧4぀のモゞュヌルをむンストヌルするこずができ、それにより、シャヌシあたり最倧64 Gbのパフォヌマンスが埗られたす。 4぀のモゞュヌルをむンストヌルしおも、宣蚀されたパフォヌマンスを備えた1぀のバランサヌがシステムに存圚するこずを意味するわけではないこずに泚意しおください。 マヌケティング担圓者はそのような数字を匕甚するのが倧奜きですが、同様に、1ダヌスのCISCO ACE 4710を取り、互いの䞊に暪たわり、玠晎らしいパフォヌマンスを埗るこずができたす。 ずころで、デバむスの䟡栌は次のずおりです。

構成䟡栌$ GPL
ACE 4710 0.5 Gbps15.995
ACE 4710 1 Gbps29.995
ACE 4710 2 Gbps39.995
ACE 4710 4 Gbps49.995
4G、1G Comp、1K SSL TPSおよび5VCを備えたACE30モゞュヌル39.995
16G、6G Comp、30K SSL TPSおよび250VCを備えたACE30モゞュヌル109.995


䟡栌リストにはオファヌがほずんどなく、䟡栌は必芁なコンテキストの数これに぀いおは埌で説明したす、SSLセッションなどによっお倧きく異なるため、おおよその䟡栌が䞎えられたす。

特城

ここでは、これらのかなり安䟡なデバむスでできるこずに぀いお少し説明したすリストは完党ではなく、䞻なものだけです。

1.アプリケヌションの切り替え。
CISCO ACEは、L4からL7の情報に基づいおサヌバヌの負荷分散を提䟛するアプリケヌションレベルのスむッチです。 HTTP、FTP、DNS、むンタヌネット制埡メッセヌゞプロトコルICMP、セッション開始プロトコルSIP、リアルタむムストリヌミングプロトコルRTSP、拡匵RTSP、RADIUS、Microsoftリモヌトデスクトッププロトコルの組み蟌みネむティブディヌプサポヌト汎甚プロトコル解析 RDP。 ぀たり、これらのプロトコルを䜿甚する堎合、ペむロヌドの情報に基づいお実際にトラフィックのバランスを取るこずができたす。

HTTPヘッダヌの操䜜远加、削陀、倉曎などず同様に、正芏衚珟のための柔軟なメカニズムがありたす。

2.トラフィック凊理。
すでに明らかになっおいるように、ACEは詳现なパケット怜査を実行できたすが、tcpdumpがあり、トラブルシュヌティングに特に圹立ちたす。

3.アドレス倉換。
゜ヌスNAT、宛先NAT、および静的NATを実装できたすただし、これはサヌバヌファヌムに1぀のサヌバヌがある堎合の前の2぀のタむプの副䜜甚ですが、それに぀いおは埌で詳しく説明したす。

4.バランスを取る方法。
サヌバヌファヌム内のサヌバヌぞのトラフィックのバランスをずるために、アプリケヌション/サヌビスの可甚性を刀断するための䞀連のテストが実行されたす。 したがっお、次のサヌバヌでバランスを取るこずができたす。 パラメヌタヌ最小負荷接続数たたはサヌバヌぞのトラフィック量、ランダムここでは、サヌバヌファヌム内の各サヌバヌに係数-重みが割り圓おられたす。特定のサヌバヌにリク゚ストを送信する確率は、重みの合蚈に察する自身の重みの比率ずしお定矩されたすしたがっお、すべおのサヌバヌの重み盞察倀が同じ堎合、バランスは均䞀になりたす、アドレスからのハッシュ、Cookieからのハッシュ、プロトコルヘッダヌからのハッシュ、URLを含むハッシュを定矩したす。 CookieたたはSSLを䜿甚する堎合、デバむスは特定のナヌザヌを特定のサヌバヌにバむンドしお、セッションの継続性を確保したす。

5.サヌビス/アプリケヌションの可甚性を決定する これがどのように構成されおいるか、埌で䟋を瀺したすICMP、TCP、UDP、ECHO {tcp | udp}、フィンガヌ、HTTP、HTTPS、FTP、Telnet、DNS、SMTP、IMAP、POP、RADIUS、スクリプト、キヌプアラむブアプラむアンスプロトコルKAL-AP、RTSP、SIP、HTTPリタヌンコヌド解析、SNMP。 たた、たずえばHTTPプロヌブを䜿甚するず、応答を受信するこずでアクセシビリティが決定されるだけでなく、必芁な応答コヌドたたはその範囲、HTTP応答のヘッダヌの必芁な倀、応答時間などを指定するこずもできたす。 サンプルを䜜成するずき、リク゚ストされたペヌゞ、ヘッダヌ倀などを決定したす。 メカニズムは非垞に柔軟です。

6.フォヌルトトレランス。 フォヌルトトレランスは、同じシャヌシ内で远加のモゞュヌル/デバむスを䜿甚するか、アクティブ/アクティブ、アクティブ/スタンバむモヌドで地理的に分離するこずで実珟されたす。 CISCO VSSを䜿甚するず、シャヌシ内の䞡方のモゞュヌルを1぀の仮想デバむスに仮想化できたす。



7.アプリケヌションの高速化。 デバむスはネットワヌクパフォヌマンスを改善するためにTCP / UDPセッションを倚重化したす。



8. SSLアクセラレヌション。 ACEにはハヌドりェアSSLアクセラレヌタが組み蟌たれおおり、デバむス䞊のセッションを終了できるため、サヌバヌの負荷が軜枛されたす。 操䜜には、SSL終了、SSL開始、゚ンドツヌ゚ンドSSL終了+開始の3぀のモヌドがありたす。 SSL終了-セッションはCISCO ACEで終了し、バランサヌからサヌバヌぞのトラフィックはクリアになりたす。 サヌバヌはバランサヌに応答し、バランサヌはデヌタを暗号化しおクラむアントに送り返したす。 1぀の興味深い機胜に泚意する必芁がありたす。バランサヌはトラフィックを解読したすが、宛先ポヌトTCPは倉曎したせん。぀たり、サヌバヌ䞊のWEBサヌバヌは80の代わりにポヌト443をリッスンする必芁がありたす。


SSL開始-クラむアントからバランサヌぞのトラフィックはクリアになり、バランサヌはサヌバヌずのSSLセッションを確立し、SSLを䜿甚しおサヌバヌず通信したす。 クラむアントぞの開口郚は、暗号化されおいない圢匏で送信されたす。

3番目のモヌドでは、クラむアントはバランサヌずの1぀のセッションを確立し、ボリュヌムはサヌバヌずの別のセッションを確立したす。 二重暗号化が発生したす暗号化された暗号化ではなく、以前に埩号化された暗号化の再暗号化を意味したす。



9.セキュリティ機胜 ACLL3-L7、双方向NATおよびPAT+ポリシヌNAT、TCP接続状態远跡、UDPの仮想接続状態、シヌケンス番号のランダム化、TCPヘッダヌ怜蚌、TCPりィンドりサむズチェック、ナニキャストリバヌスチェックセッションの確立時のパス転送URPF、レヌト制限。

10.仮想化機胜。
デバむスは唯䞀のデバむスずしお機胜したすが、垞に柔軟であるずは限りたせん。 たたは、1぀の物理デバむスから最倧250の仮想バランサヌを䜜成できたす。 そのような各バランサヌには、独自の管理者、独自の構成、独自のルヌル、および䜿甚されるリ゜ヌスCPU、接続、垯域幅の制限がありたす。 自分のニヌズに非垞に適しおいるだけでなく、専甚のACEサヌビスを顧客に提䟛するこずもできたす。そこでは、デバむス内で䜕でもやりたいこずができたす。


11.動䜜モヌド ルヌテッドモヌド、ブリッゞモヌド、非察称サヌバヌ正芏化ASN。 ルヌタヌモヌドでは、むンラむンずオンスティックたたはワンアヌムモヌドの2぀のサブモヌドを区別できたす。

ブリッゞモヌド

デバむスは、サヌバヌずサヌバヌのデフォルトゲヌトりェむの間の「ギャップ」にありたす。 L2ブリッゞモヌドの同じサブネット䞊の䞡方のデバむスむンタヌフェむス。 前提条件は、CISCO ACEを経由しないサヌバヌずルヌタヌ間のトラフィックの䞍足です。 したがっお、クラむアントはVIP 172.16.3.100仮想IP-バランサヌの仮想アドレス。それに到着するトラフィックVIPはサヌバヌ間で分散されたすにアクセスし、デバむスはリク゚ストをサヌバヌにリダむレクトし、宛先アドレスを倉曎したす。 サヌバヌは172.16.3.1に応答を送信したすが、トラフィックがACEを通過するずそしお、それが必須であるず蚀いたした、゜ヌスアドレスは172.15.3.100に戻りたす。

この゜リュヌションは、既存のネットワヌクでのCISCO ACEの実装に適しおいたす。アドレス指定は倉曎されず、サヌバヌの再構成は実行されたせん。

ルヌテッドむンラむンモヌド

このモヌドでは、CISCO ACEはトラフィックを枡すためのホップを実行したす。 このモヌドは、新芏むンストヌルに適しおいたす。 バランサヌはサヌバヌのデフォルトゲヌトりェむです。 このモヌドでは、さらに詳しく説明し、バランスを取るための䞀般的な構成を瀺したす。

ルヌテッドモヌドOn-a-stickワンアヌムモヌド

ナヌザヌからのトラフィックはバランサヌVIPに到達したす。 クラむアントアドレスは、独自のバランサヌアドレス、宛先アドレスは実際のサヌバヌアドレスたたは実際のサヌバヌアドレスの1぀に眮き換えられたす。 この堎合、サヌバヌはバランサヌに盎接応答し、手順は逆の順序で繰り返されたす。゜ヌスアドレスがVIPに倉曎され、宛先アドレスがクラむアントアドレスに倉曎されたす。 クラむアントはアドレスVIPを䜿甚しおサヌバヌず通信する印象を持っおいたすが、実際にはサヌバヌは䞖界䞭に配眮できたす。

クラむアントがバランスサヌビスを取埗したい堎合に適したオプションです。 たずえば、クラむアントには、異なるDCに3぀のWEBサヌバヌがありたす。 私たちから、圌はバランサヌの実際のIPアドレス–VIPを受け取りたす。 蚭定では、DNSはそのドメむンを専甚のVIPにバむンドしたす。 これで、クラむアントはサヌバヌを「シャむニング」せず、サヌバヌを远加たたは削陀するだけでなく、クラむアントは匕き続きサヌビスを受けたす。

ルヌテッドモヌドの非察称サヌバヌの正芏化
モヌドは以前のモヌドず非垞に䌌おいたす。この堎合、サヌバヌはクラむアントに盎接応答し、CISCO ACEをバむパスしたす。

蚭定䟋を怜蚎しおください

倚くのオプションを説明せずに基本的な䟋を怜蚎したいず思いたす。これは緊急の必芁がないため良い資料ぞのリンクを提䟛したす、必芁に応じお、䞍明な点をコメントたたは説明する方が良いです。

トポロゞヌずしお、私たちはご飯を取りたす。 ルヌテッドむンラむンモヌド。
管理むンタヌフェむス172.16.1.5。

制埡ポリシヌのルヌルを曞きたしょう。
class-map type management match-any L4_REMOTE-ACCESS_CLASS
description Enabling remote access traffic to the ACE and the Cisco ACE Module
2 match protocol ssh source-address 172.16.1.0 255.255.255.0
3 match protocol icmp source-address 172.16.1.0 255.255.255.0
4 match protocol https source-address 172.16.1.0 255.255.255.0
5 match protocol snmp source-address 172.16.1.0 255.255.255.0

policy-map type management first-match L4_REMOTE-ACCESS_MATCH
class L4_REMOTE-ACCESS_CLASS
permit

interface vlan 20
ip address 172.16.1.5 255.255.255.0
service-policy input L4_REMOTE-ACCESS_MATCH

ネットワヌク172.16.1.0/24から、SSH、SNMP、HTTPS、ICMPプロトコルを䜿甚しおデバむスにアクセスできたす。

サヌバヌファヌムに3台のサヌバヌがあり、その䞊で負荷を分散したす。 サヌバヌを宣蚀したす。

rserver host SERVER-1
description SERVER-1
ip address 192.168.1.11
inservice
rserver host SERVER-2
description SERVER-2
ip address 192.168.1.12
inservice
rserver host SERVER-3
description SERVER-3
ip address 192.168.1.13
inservice

サヌバヌをファヌムに統合したすサンプルでは、​​HTTPずICMPを䜿甚したす。
serverfarm host FARM
probe HTTP_PROBE
probe ICMP_PROBE
rserver SERVER-1
inservice
rserver SERVER-2
inservice
rserver SERVER-3
inservice

サンプルの説明
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

interval-サンプル間の間隔
receive-応答タむムアりト
passdetectカりント-あたり倚くの回答を受け取らない堎合、サヌバヌは利甚䞍可ず芋なされたす
passdetect interval-䜿甚できないサヌバヌのサンプル間隔

バランスポリシヌに぀いお説明したす。
仮想IPアドレスポヌト80でのみリク゚ストを受け付けたす
class-map match-all FARM-VIP
2 match virtual-address 172.16.1.100 any eq www

ファヌムぞのトラフィックのバランスを取りたす。぀たり、バランスポリシヌを説明したす。
policy-map type loadbalance http first-match FARM_POLICY
class class-default
serverfarm FARM

HTTPバランシングのタむプを蚭定しない堎合これは必芁ありたせん、HTTPプロトコルを䜿甚するず、たずえばCookieで問題が発生する可胜性がありたす。 このパラメヌタは、将来のトラフィックず凊理機胜のタむプを決定したす。 「バスケット」の問題



これは、FARM_POLICYポリシヌが割り圓おられるHTTPトラフィックがFARMファヌムにルヌティングされるこずを意味したす。

次に、䞊蚘を組み合わせたポリシヌを䜜成したす。

policy-map multi-match WWW-PM
class FARM-VIP
loadbalance vip inservice
loadbalance policy FARM_POLICY
loadbalance vip icmp-reply active

このポリシヌは、入力倖郚むンタヌフェヌスに適甚できたす。
interface vlan 20
service-policy input WWW-PM

これは、たず、アドレス172.16.1.100を芁求するずきにバランサヌがMACを提䟛するこずを意味したす。 さらに、トラフィックがアドレス172.16.1.100class-map match-all FARM-VIPのポヌト80に向かう堎合、蚘述されたバランシングルヌルloadbalance policy FARM_POLICY、぀たりすべおclass class-default FARMファヌムserverfarm FARMに送信したす。 CISCO ACEは、このアドレスぞのpingにも応答したすloadbalance vip icmp-reply active。

サヌバヌの応答が䞀般に正しいアドレスでクラむアントに届くようにするには、内郚サヌバヌアドレスから倖郚VIPアドレスぞの倉換を䜜成する必芁がありたす。

たた、すべおのむンタヌフェむスで、すべおを蚱可するACLを远加したす。 他の堎所でトラフィックをフィルタリングしおいるこずを意味したす。 CISCO ACEはデフォルトですべおのトラフィックをブロックしたす。

access-list PERMIT-ANY line 8 extended permit ip any any

access-list NAT line 1 extended permit ip host 192.168.1.11 any
access-list NAT line 2 extended permit ip host 192.168.1.12 any
access-list NAT line 3 extended permit ip host 192.168.1.13 any

class-map match-any PAT-ClassMap
2 match access-list NAT

policy-map multi-match NAT-PM
class PAT-ClassMap
nat dynamic 1 vlan 20

interface vlan 20
access-group input PERMIT-ANY
nat-pool 1 172.16.1.100 172.16.1.100 netmask 255.255.255.255 pat

interface vlan 40
ip address 192.168.1.1 255.255.255.0
access-group input PERMIT-ANY
service-policy input NAT-PM


FWSMASA、PIXでは、NATは数倍簡単に構成されたす。

小さなタッチデフォルトルヌト、SNMP
ip route 0.0.0.0 0.0.0.0 172.16.1.1

snmp-server community xxx group Network-Monitor
snmp-server user user_name Network-Monitor auth sha p@ssword localizedkey
snmp-server host 172.16.1.2 traps version 2 xxx

リンクhttp://pastebin.com/DV4QM2Yaをクリックしお、完党な構成を芋぀けたす。 機胜を実蚌するために、CISCO ACEにはナヌザヌネットワヌクぞのむンタヌフェむスがありたす。 ナヌザヌに察しおは、PATの機胜を実行し、FTPプロトコルを怜査しお、このプロトコルに問題がないようにしたすアクティブ/パッシブモヌド。

受け取ったものの監芖ベヌス
ACE # show serverfarm FARM
serverfarm : FARM, type: HOST
total rservers : 2
---------------------------------
----------connections-----------
real weight state current total failures
---+---------------------+------+------------+----------+----------+---------
rserver: SERVER-1
192.168.1.11:0 8 OPERATIONAL 44 52841950 12274606
rserver: SERVER-2
192.168.1.11:0 8 OPERATIONAL 49 51043947 13091531


ACE-MEL/Admin# show serverfarm FARM detail
serverfarm : FARM, type: HOST
total rservers : 2
active rservers: 2
description : -
state : ACTIVE
predictor : ROUNDROBIN
failaction : -
back-inservice : 0
partial-threshold : 0
num times failover : 0
num times back inservice : 0
total conn-dropcount : 44
Probe(s) :
HTTP_PROBE, type = HTTP
ICMP_PROBE, type = ICMP

---------------------------------
----------connections-----------
real weight state current total failures
---+---------------------+------+------------+----------+----------+---------
rserver: SERVER-1
192.168.1.11:0 8 OPERATIONAL 44 52841981 12274606
description : -
max-conns : - , out-of-rotation count : -
min-conns : -
conn-rate-limit : - , out-of-rotation count : -
bandwidth-rate-limit : - , out-of-rotation count : -
retcode out-of-rotation count : -
load value : 0

rserver: SERVER-1
192.168.1.11:0 8 OPERATIONAL 49 51043976 13091532
description : -
max-conns : - , out-of-rotation count : -
min-conns : -
conn-rate-limit : - , out-of-rotation count : -
bandwidth-rate-limit : - , out-of-rotation count : -
retcode out-of-rotation count : -
load value : 0


ACE # show rserver SERVER-1

rserver : SERVER-1, type: HOST
state : OPERATIONAL (verified by arp response)
---------------------------------
----------connections-----------
real weight state current total
---+---------------------+------+------------+----------+--------------------
serverfarm: FARM
192.168.1.11:0 8 OPERATIONAL 13 1288706

そしお、さらに倚くのチヌム。

たずめるず

この蚘事では、CISCOからだけでなく、䞀般的にデヌタセンタヌむンフラストラクチャのかなり重芁な郚分ずしおバランサヌを䜿甚しお、読者にこの機噚を少し玹介したかったのです。 私の頭の䞭で倚くの情報が回っおいたすが、その投皿はそれほど小さくはないようです。

そのため、このようなデバむスの䞻な目的は、サヌビス間の負荷分散可甚性の向䞊、パフォヌマンスの向䞊、リ゜ヌスの統合、サヌバヌからハヌドりェアアクセラレヌタぞのSSL終了機胜の転送、セキュリティの改善正芏化およびその他の独自技術のおかげ、TCP /アクセラレヌションですUDP倚重化、圧瞮による。

たた、1぀のデヌタセンタヌの通路だけでなく、地理的に離れたサヌビス間でバランスを取る可胜性も泚目に倀したす。

ACE20-MOD-K9 4Gbpsモゞュヌルを䜿甚したす。 もちろん、すべおの4Gbpsでロヌドされるわけではありたせんが、タスクを実行したす。 操䜜䞭、問題はありたせんでした;それは非垞によく確立されおいたす。 なぜ私はこれに぀いお曞き始めたのですか。 実際、特にリ゜ヌスetherealmind.comで、CISCO ACEに察する肯定的なレビュヌを聞いたこずはありたせん。 たたは、䜕も曞かないでください。 ほずんどの堎合、フリヌズ、IOSバギヌ、䞍安定性に぀いお䞍平を蚀いたす。 ACEを備えたCISCOは、他の補品よりも先を行っおいるわけではありたせん。 ゚ンゞニアはF5の補品を非垞に匷く賞賛し、同時に子䟛の䟡栌からはほど遠いこずに泚目しおいたす。 私はこの機噚に遭遇したこずはありたせんが、䞀般的に、私たちの地域では珍しいものであり、そのような機噚を芋たこずはありたせん。

読者が䜕かをもっず詳しく知りたいずいう願望を持っおいるなら、私は助けようずするか、別のメモを曞きたす。

私は、同様の機噚で働いた/働いおいる人々のコメントず意芋を本圓に楜しみにしおいたす。 実際、このトピックは実際にはHabréには觊れおいたせんでした。

CIS ACE。 パヌト2リモヌトサヌバヌずアプリケヌションのバランスをずる

゜ヌス
1. CISCOドキュメント、cisco.com。
2. vivekganapathi.blogspot.com/2010/07/cisco-ace-4710-load-balancer.html
3.www.packetslave.com/2010/01/24/cisco-ace-basic-http-load-balancing
4. docwiki.cisco.com/wiki/Cisco_Application_Control_Engine_ACE_Configuration_Examples
5. etherealmind.com/cisco-ace-load-balance-stick-source-nat-part-1
6. etherealmind.com/cisco-ace-load-balance-stick-source-nat-part-2
7. etherealmind.com/cisco-ace-load-balance-stick-source-nat-part-3
8. etherealmind.com/cisco-ace-fwsm-resource-allocation-for-virtualization
9. www.cisco.com/en/US/products/hw/modules/ps2706/products_configuration_example09186a00809c3041.shtml

Source: https://habr.com/ru/post/J143564/

More articles:


All Articles