Diplomarbeit Skalierbare Hochverfügbarkeitslösungen mit Lastverteilung für E-Commerce Sites Mai 2000
4.3 Lösungsansatz mit High Availability und Load Balancing
Bei einer Unternehmensanbindung, welche neben Hochverfügbarkeit auch die parallele Nutzung von Firewalls oder Routern bieten soll, muß Load Balancing mit Hilfe von Layer4-Switches zum Einsatz kommen. Durch den Einsatz der Layer4-Switches kann der Ausfall einer Firewall oder eines Routers registriert und die Datenlast auf die restlichen Geräte verteilt werden. Der Einsatz einer High Availability-Technologie zwischen den Firewalls ist deshalb nicht mehr notwendig. Da die Layer4-Switches in der Lage sind, mehrere Geräte anzusprechen, kann bei ansteigender Netzwerklast die Anzahl der eingesetzten Firewalls oder Router flexibel den Erfordernissen angepasst werden.
Eine entsprechende Topologie ist in Abb. 4.5 dargestellt. Hierbei werden drei Paare von Layer4-Switches eingesetzt, um die Last auf die Firewalls zu verteilen. Ein weiteres Paar von Layer4-Switches wird zur Lastverteilung auf die Internetanbindungen verwendet.
Abhängig vom eingesetzten Modell arbeiten einige Layer4-Switches mit dem Hot-Standby-Modus158 , so dass immer nur ein Gerät aktiviert ist, während bei anderen Modellen sämtliche Switches einer Gruppe aktiviert sind.159 In letzterem Fall können weitere Layer4-Switches eingesetzt werden, um den maximalen Datendurchsatz zu erhöhen. Es muß dabei berücksichtigt werden, dass bei nur einem aktiven Gerät dessen maximaler Datendurchsatz den möglichen Durchsatz aller Firewalls begrenzt.
Die in diesem Lösungsansatz verwendeten L4-Switches arbeiten im Hot-Standby-Modus, d.h. das jeweilig aktive Gerät ist über eine virtuelle IP-Adresse erreichbar. Bei einem Geräteausfall aktiviert sich das Standby-Gerät und akzeptiert ab sofort alle an die virtuelle IP-Adresse gerichteten Pakete. Beim Einsatz mehrerer gleichzeitig aktiver L4-Switches muß jedes Gerät über eine eigene IP-Adresse angesprochen werden.
Die L4-Switches überprüfen gegenseitig ihre Funktionsfähigkeit entweder über eine direkte Verbindungen untereinander oder über eine benachbarte Netzsegment-Verbindung. In letzterem Fall müssen die jeweils verwendeten Interfaces spezifiziert werden.
Abbildung 4.5 : Internetanbindung mit High Availability und Load Balancing
Mit Hilfe von L4-Switches wie z.B. Linkproof von RADWare kann die Last auf die Standleitungen der Internetanbindung verteilt werden. Der ausgehende Datenverkehr wird dynamisch auf die Border Router verteilt, welche dann die Pakete mittels ihrer eingetragenen Default Routes über die Standleitung zum ISP senden. Der Einsatz von BGP4 auf den Border Routern wird nicht benötigt. Sofern der L4-Switch in der Lage ist, über einen ICMP-Ping den günstigsten Weg eines Paketes festzustellen, werden diese Informationen in die Load Balancing-Entscheidung mit einbezogen. Bei einem Bezug des IP-Adressraumes von nur einem ISP werden die ankommenden Pakete gemäß der in Kap. 3.5 beschriebenen Regeln auf die Standleitungen aufgeteilt, es findet also nur ein Load Sharing statt. Dies gilt ebenso bei einem IP-Adressraum von einer Internet Registry. Wenn allerdings von jedem ISP ein eigener IP-Adressraum zur Verfügung gestellt wird, kann mit Hilfe einer NAT auf den L4-Switches der Antwortverkehr gezielt auf die Standleitungen verteilt werden. Dazu wird die Quell-IP-Adresse eines ausgehenden Paketes entsprechend des ISPs geändert, über den der Weg des dazugehörigen Antwortpaketes gewünscht ist.
Der L4-Switch überwacht den Zustand und die Erreichbarkeit von ISP, Standleitung, Border Router und L2-Switch und kann bei einem Ausfall sämtliche Pakete an den noch erreichbaren ISP senden. Deshalb ist der Einsatz von VRRP auf den Border Routern nicht nötig.
Layer4-Switches, wie z.B. Fireproof von RADWare, die zur Lastverteilung auf Firewalls eingesetzt werden, müssen in der Lage sein, sämtliche Pakete einer Session immer über dieselbe Firewall zu leiten, da sonst das Paket verworfen werden kann.160 Desweiteren wird von den L4-Switches die Funktionalität der Firewalls überwacht, so dass ein Ausfall erkannt und die Pakete ab diesem Zeitpunkt über die anderen Firewalls geleitet werden können. Die Sessions werden anhand bestimmter Verteilungsschlüssel wie Least Connections oder Weighted Percentage auf die Firewalls verteilt.161 Bei Paketen einer schon bestehenden Session findet kein Load Balancing statt; diese werden auf die Firewall geleitet, auf der diese Session akzeptiert wurde, da nur sie über einen Eintrag in ihrer Session-Tabelle verfügt.
Die Redundanz und Ausfallüberwachung der restlichen Router, Layer2-Switches und Verbindungskabel entspricht Kap. 4.2 und wird hier nicht weiter erläutert.
Abbildung 4.6 : Routenverlauf innerhalb einer HA-Lösung mit Load Balancing
Die Pakete werden wie bei der Lösung in Kap. 4.2 entweder über Static Routes oder über Default Routes weitergeleitet. Default Routes werden verwandt für alle Pakete, deren Ziel im Internet liegt und Static Routes für alle Pakete, deren Ziel innerhalb des Unternehmensnetzes liegt, da hier das Ziel bekannt ist. Der Next-Hop der Routen ist jeweils die virtuelle IP-Adresse der nächsten Router- oder Layer4-Switch-Gruppe, wodurch auch bei einem Geräteausfall die Routingeinträge noch ihre Gültigkeit behalten. Von den L4-Switches weitergeleitete Pakete werden individuell an die jeweiligen Router oder Firewalls adressiert. Die Einteilung der Routen ist in Abb. 4.6 dargestellt.
Die hier vorgestellte Lösung ist zwar relativ kostenintensiv, bietet aber volle Redundanz bei gleichzeitiger Skalierbarkeit der Anzahl der Standleitungen und Firewalls durch Load Balancing. Solange nicht zwei benachbarte Geräte gleichzeitig ausfallen, kann die Internetanbindung aufrecht erhalten werden. Der Ausfall z.B. einer Standleitung kann zwar von der anderen Standleitung nicht vollständig kompensiert werden, die Erreichbarkeit ist jedoch gewährleistet.
Bei einer Zunahme des Datenverkehrs können zudem weitere Router, Standleitungen und Firewalls zugeschaltet werden, ohne dass zusätzliche weitere Hardware benötigt wird.
158z.B. Fireproof von RADWare
159z.B. Serveriron von Foundry
160vgl. Kap. 3.4
161vgl. Kap. 3.3