VPNセッションを役割別に拡張し、障害時の余裕を確認する
リモートアクセスの負荷分散、フェイルオーバー、サイト間クラスタリングは別々の仕組みです。購入した総数ではなく、一台のゲートウェイ障害後に残る数を数えてください。
二台目のゲートウェイを追加しても、コンソールに健全なメンバーが二台と表示されるだけで、セッションの上限はほとんど動きません。新しい筐体への到達方法がクライアントに伝わっていないからです。VPNサービスの拡張は、この接続種別でクライアントを分散する仕組みはどれか、そして最悪の単一障害後にどれだけの容量が残るかという、順序立った二つの判断です。逆の順序で決めると冗長に見えて必要なときにちょうど失敗する設計になるので、まずコンソールを確認し、それから計算してください。
仕組みをセッション種別に合わせる
リモートユーザー、サイト間ピア、常時接続のデバイストンネルは互換性のあるセッションではありません。どれか一つ向けに作られた分散機能は通常、ネゴシエーション中にクライアントを転送しますが、固定アドレスと静的設定をすでに持つピアには何の意味もありません。
CiscoのASA高可用性ガイドは、リモートアクセスVPNの負荷分散、ステートフルフェイルオーバー、サイト間クラスタリングという三つの機能を区別しています。グループエントリからメンバーへ適格なクライアントを移動するのは最初の一つだけで、LAN間接続はその分散の対象外です。汎用のTCPロードバランサーは、トンネルのハンドシェイクがプロキシで書き換えられる単純なHTTPではないため、プロトコル自身のリダイレクト手順を代替できません。実際の結果は、接続を受け入れてもクライアントがトンネルを張れないバランサーです。
二台目の機器を発注する前に、機能一覧を自分のセッション種別と照らし合わせて読んでください。ライセンスの行と仕組みの行は別の項目であり、片方がもう片方を意味するわけではありません。
推測せずに例を計算する
承認したワークロードの下で、三台のゲートウェイがそれぞれ800同時トンネルで検証されているとすると、合計は2,400です。ピーク時間帯の目標1,650は余裕に見えますが、一台を失うと、生き残った二台で厳しい1,600に対して1,650を保持しなければなりません。設計はすでに破綻しており、フェイルオーバーの調整では算術は直りません。
生き残った集合が依然として目標を満たすよう、三メンバーのグループでは合計の三分の二を下回るように設定してください。この比率は算術の性質であり製品の性質ではないので、メンバーの検証値が変わったら再計算してください。ライセンス数、文書化された上限、自分で測った値を三列に保ち、これらはめったに一致しないため最も小さい値が支配します。観測したピーク時間帯のピークを四列目に置けば、最初の一か月後も計画は誠実であり続けます。
再接続の波に備え、定常状態だけを見ない
障害が起きたメンバーのセッションは、静かに別の場所へ現れるわけではありません。仕組みによって、状態付きで引き継がれるか、ゼロから再ネゴシエーションするか、アプリケーションが独自のスケジュールで再試行するのを待ちます。
一分以内に数千のクライアントが再試行することは、安定した1,650とは別の出来事であり、認証サーバーが最初にそれを感じます。プールの空きも、リダイレクトはプールを参照しないため、アドレスを割り当てられないメンバーがクライアントを受け入れたままそのトラフィックを落とす点も確認してください。
プールと経路を手元に置いて容量を検証する
検証は読み取りだけの作業で、保守作業の時間帯が始まる前にほとんどの設計ミスを捕まえます。メンバーごとのプール、アクティブなセッション数、クライアントサブネットへの戻り経路を集め、それぞれを計画と比較してください。プールの枯渇も戻り経路の欠落も、認証に成功した後にトラフィックを失うクライアントとして現れます。
show vpn-sessiondb summary
show running-config ip local pool
show vpn load-balancing
show route 10.40.12.0 255.255.255.0
これらの読み取りは、静かな時間帯ではなく通常のピーク時間帯に各メンバーへ実行してください。セッションを報告していても空きアドレスがないメンバーは、ライセンスが何と言おうと実用上の限界に達しています。コマンド名はリリース間で変わるため、各出力の横にファームウェアのバージョンを記録してください。
業務時間外に、意図的に一度だけ損失を演習し、その間に生き残ったメンバーが何を報告するかを記録してください。リダイレクトを受け入れてもプールに空きがないメンバーは、割り当て失敗として現れ、追加の帯域幅では決して直りません。検証済みの数値は日付とともに計画の横に保存し、次の容量レビューがライセンス表ではなく証拠から始まるようにしてください。その演習の結果は、数値が計画と一致した場合でも同じページに追加してください。