Skalieren Sie VPN-Sitzungen nach Rolle und prüfen Sie dann die Ausfallreserve

Sie fügen ein zweites Gateway hinzu, die Konsole zeigt zwei gesunde Mitglieder, und die Sitzungsobergrenze bewegt sich kaum, weil niemand den Clients gesagt hat, wie sie die neue Box erreichen. Einen VPN-Dienst zu skalieren sind zwei Entscheidungen in Folge: welcher Mechanismus die Clients für diesen Verbindungstyp verteilt und wie viel Kapazität nach dem schlimmsten Einzelverlust übrig bleibt. Nimmt man sie in umgekehrter Reihenfolge, entsteht ein Entwurf, der redundant aussieht und genau dann versagt, wenn er gebraucht wird. Beginnen Sie an der Konsole und rechnen Sie dann.

Ordnen Sie den Mechanismus dem Sitzungstyp zu

Remote-Benutzer, Site-to-Site-Peers und dauerhaft aktive Gerätetunnel sind keine austauschbaren Sitzungen. Eine Verteilungsfunktion, die für eine davon gebaut wurde, leitet einen Client normalerweise während der Aushandlung um, was für einen Peer nichts bedeutet, der bereits eine feste Adresse und eine statische Konfiguration hat.

Ciscos Leitfaden für Hochverfügbarkeit von ASA hält drei Fähigkeiten getrennt: Lastverteilung für Remote-Access-VPN, zustandsbehaftetes Failover und Site-to-Site-Clustering. Nur die erste verschiebt einen geeigneten Client von einem Gruppeneintrag zu einem Mitglied, und LAN-zu-LAN-Verbindungen bleiben außerhalb dieser Verteilung. Ein generischer TCP-Loadbalancer kann den eigenen Umleitungsschritt des Protokolls nicht ersetzen, weil der Tunnel-Handshake kein einfaches HTTP ist, das ein Proxy umschreiben kann. Das praktische Ergebnis ist ein Loadbalancer, der die Verbindung annimmt und den Client trotzdem nicht tunneln lässt.

Lesen Sie die Funktionsliste gegen Ihren Sitzungstyp, bevor Sie ein zweites Gerät bestellen. Die Lizenzzeile und die Mechanismuszeile sind getrennte Einträge, und eine impliziert die andere nicht.

Rechnen Sie das Beispiel durch, statt zu raten

Angenommen, drei Gateways sind jeweils auf 800 gleichzeitige Tunnel unter der von Ihnen freigegebenen Last validiert, was insgesamt 2,400 ergibt. Ein Spitzenstundenziel von 1,650 wirkt bequem, bis eine Einheit verloren geht, und dann muss das überlebende Paar 1,650 gegen harte 1,600 halten. Der Entwurf ist bereits gescheitert, und kein Failover-Tuning repariert die Arithmetik.

Setzen Sie das Ziel so, dass das überlebende Set es noch erfüllt, was für eine Gruppe aus drei Mitgliedern bedeutet, unter zwei Dritteln der Gesamtzahl zu bleiben. Dieses Verhältnis ist eine Eigenschaft der Arithmetik und nicht eines Produkts, also rechnen Sie es neu, wenn sich die validierte Zahl eines Mitglieds ändert. Halten Sie die lizenzierte Anzahl, das dokumentierte Maximum und Ihre eigene gemessene Zahl in drei Spalten, weil sie selten übereinstimmen und die kleinste maßgeblich ist. Eine vierte Spalte für die beobachtete Spitzenlast hält den Plan nach dem ersten Monat ehrlich.

Kalkulieren Sie den Wiederverbindungsschwall, nicht nur den Dauerzustand

Sitzungen auf einem ausgefallenen Mitglied tauchen nicht stillschweigend woanders wieder auf. Je nach Mechanismus werden sie mit Zustand übernommen, von Grund auf neu ausgehandelt oder warten darauf, dass die Anwendung nach ihrem eigenen Zeitplan erneut versucht.

Ein paar tausend Clients, die innerhalb einer Minute erneut versuchen, sind ein anderes Ereignis als stabile 1,650, und die Authentifizierungsserver spüren es zuerst. Prüfen Sie auch den Pool-Platz, denn die Umleitung fragt ihn nicht: Ein Mitglied, das keine Adresse zuweisen kann, nimmt den Client trotzdem an und verwirft dann seinen Verkehr.

Verifizieren Sie die Kapazität mit Pool und Route zur Hand

Die Verifikation ist eine reine Leseübung, die die meisten Entwurfsfehler abfängt, bevor ein Wartungsfenster öffnet. Sammeln Sie den Pool pro Mitglied, die Anzahl der aktiven Sitzungen und die Route zurück zum Client-Subnetz und vergleichen Sie jeden Wert mit dem Plan. Pool-Erschöpfung und eine fehlende Rückroute zeigen sich beide als ein Client, der sich authentifiziert und dann Verkehr verliert.

show vpn-sessiondb summary
show running-config ip local pool
show vpn load-balancing
show route 10.40.12.0 255.255.255.0

Führen Sie diese Lesezugriffe an jedem Mitglied während einer normalen Spitzenstunde aus, nicht in einer ruhigen. Ein Mitglied, das Sitzungen meldet, aber keine freien Adressen hat, ist bereits an seiner praktischen Grenze, was auch immer die Lizenz sagt. Notieren Sie die Firmware-Version neben jeder Ausgabe, da sich Befehlsnamen zwischen Releases ändern.

Üben Sie den Verlust einmal absichtlich außerhalb der Geschäftszeiten und protokollieren Sie, was die überlebenden Mitglieder währenddessen melden. Ein Mitglied, das die Umleitung akzeptiert, aber keinen Pool-Platz hat, erscheint als fehlgeschlagene Zuweisung, was zusätzliche Bandbreite nie behebt. Speichern Sie die validierten Zahlen mit dem Datum neben dem Plan, damit die nächste Kapazitätsprüfung mit Belegen statt mit einer Lizenz-Tabelle beginnt. Fügen Sie das Ergebnis dieser Übung derselben Seite hinzu, auch wenn die Zahlen zum Plan passen.