NetScaler High Availability | Hochverfügbarkeit

Ein wie selbstverständlich schon genanntes Feature des NetScalers ist der Betrieb in einem Verbund mehrerer Systeme zur Sicherstellung von Hochverfügbarkeit. Durch seine Funktionalität als intelligenter Load Balancer stellt der NetScaler Hochverfügbarkeit für die Backend Services her, die er beliefert, wird damit aber zugleich zum hochkritischen Punkt der Infrastruktur, von dessen Verfügbarkeit zahlreiche zentrale Dienste abhängig sind.

Active/Standby Modus im NetScaler

Die am Häufigsten eingesetzte und angebrachte Variante der HA Modus ist Active/Standby. In dieser Betriebsart bilden zwei NetScaler Appliances ein HA Paar, in dem lediglich die NSIPs individuell sind, während alle anderen Adressen „floating“ beim Failover vom Standby System übernommen werden. Konfigurationsänderungen sind nur auf dem aktiven Knoten (Primary) möglich bzw. dauerhaft. Solange beide Systeme in Betrieb sind, werden alle auf dem Primary ausgeführten Kommandos (also alle Konfigurationsänderungen) per „Command Propagation“ auch auf dem Secondary Node ausgeführt. Bei einem Reboot zieht sich das startende Standby System die Konfiguration einmal komplett vom Primary Node (HA Synchronization).

Active/Standby mit INC

Eine Spielart des Active/Standby Modus ist die Independent Network Configuration (INC), die dann erforderlich ist, wenn ein HA Paar auf zwei Standorte verteilt ist, in denen unterschiedliche IP-Netze verwendet werden oder zwischen denen die Layer 2 Verbindung ausfallen könnte oder gar nicht erst existiert. Die INC erlaubt es jedem Knoten im HA Paar, die Backends jederzeit selbst zu überwachen und damit auch ohne Verbindung mit dem HA Partner den Monitor Status zu kennen, da neben der NSIP auch die SNIPs/MIPs individuell und damit jederzeit aktiv sind. Im Unterschied zu einem Deployment mit Global Server Load Balancing (GSLB), das als nächste Abstraktionsstufe der Hochverfügbarkeit gelten kann, handelt es sich aber immer noch um ein HA Paar, das eine gemeinsame Konfiguration synchronisiert.

Befinden sich die Knoten nicht im selben Layer 2 Segment, müssen die VIPs wiederum per Route Health Injection bekannt gemacht werden, d.h. es muss ein dynamisches Routing Protokoll zum Einsatz kommen. Anderenfalls reicht der normale IP Failover mit anschließender Gratuitious ARP (GARP) Bekanntgabe an alle Teilnehmer des Segmentes aus.

NetScaler Pools, Active/Active

Zu einem HA Deployment können auch mehr als zwei NetScaler verbunden werden, wir sprechen dann von NetScaler Pools. Zwar ist auch ein Deployment mit mehr als einem Standby System möglich (Active/Standby/Standby/…), aber in der Praxis sind NetScaler Pools vor allem sinnvoll in Situationen, wo mehr aktive Leistung benötigt wird, als eine einzelne Appliance liefern kann. In Anbetracht der Leistungsmerkmale der MPX Hardware Appliances sind diese Situationen zwar äußerst selten, aber auch dieser Ansatz zur Skalierung kann wünschenswert sein (z.B. sehr hohe Durchsatzanforderung für FIPS-zertifiziertes Deployment). Ein NetScaler Pool mit mehreren aktiven Knoten ist eine Erweiterung eines einfachen Active/Active Paares, um zusätzliche Failover Kapazität (N+1 oder auch N+X) und Leistung.

Bei Active/Active Deployments besteht kein HA Paar im Sinne von gemeinsamer Konfiguration oder gemeinsamen IP Adressen, alle NetScaler laufen standalone. Die Zuordnung von VIPs zu Systemen erfolgt mit Hilfe des Virtual Router Redundancy Protocols (VRRP), indem jedem NetScaler für jede VIP eine Priorität zugewiesen wird. Die Systeme regeln dann untereinander, welche VIP zu einem Zeitpunkt auf welchem NetScaler aktiv ist. Dabei wandert gemäß VRRP auch eine Virtual MAC (VMAC), die zu jeder VIP gehört und aus der Virtual Router ID (VRID) gebildet wird, beim Failover mit auf den nächsten NetScaler.

Als weitere Konsequenz aus der Tatsache, dass die Systeme in einem NetScaler Pool keine Synchronisationsmöglichkeit haben, müssen zur Sicherstellung von Session Persistence verbindungslose („stateless“) Methoden eingesetzt werden. Beispiele dafür sind Hash-basierte Persistenz und vor allem Cookie Insert, bei dem der Client seine Persistenz-Informationen praktisch selbst besitzt und mitliefert.

VMACs und Firewall Load Balancing

Bei einem IP Failover wird die neue Heimat einer IP-Adresse durch GARP Pakete bekanntgegeben. Sicherheitskritische Systeme beachten diese Pakete unter Umständen nicht weiter, da ihnen damit auch gefälschte ARP Einträge untergeschoben werden könnten, so dass es zu längeren Unterbrechungen im Falle eines Failovers kommen kann. Hier, wie auch speziell im Sonderfall des Firewall Load Balancing, das in der Regel sowieso auf Layer 2 stattfindet, sind virtuelle MAC Adressen (VMACs) hilfreich. Diese können ebenso zwischen NetScalern wandern wie IP-Adressen, so dass keine Neuzuordnung von IP zu MAC mehr erforderlich ist.

Auslöser für ein Failover

Neben der völligen Unerreichbarkeit des bislang aktiven Partners gibt es weitere Auslöser – oder auch Hinderungsgründe – für ein Failover der Ressourcen auf einen Standby NetScaler. So kann die Erreichbarkeit eines HA Partners abhängig sein von der Verfügbarkeit von Routern, so dass diese ein Entscheidungskriterium dafür sind, ob ein System überhaupt beurteilen kann, ob der Partner oder nur die Verbindung offline ist. Zu diesem Zweck können Route Monitors der HA Konfiguration hinzugefügt werden, die kritische (statische) Routen oder die bloße Existenz bestimmter dynamischer Routen überwachen und bei negativer Verfügbarkeit verhindern, dass dieser Knoten aktiv werden kann.

Weiterhin überwachte Ressourcen sind die Netzwerkschnittstellen eines NetScalers. Standardmäßig werden alle verbundenen Interfaces überwacht und der Verlust des Links an einem Interface führt zum Failover auf den Standby Node. Die schon beschriebene Link Aggregation zur Erhöhung der verfügbaren Bandbreite, durch die auch die Abhängigkeit von einem einzelnen Interface aufgehoben wird, muss für die HA Konfiguration in Form eines Failover Interface Set (FIS) abgebildet werden. Beim Ausfall eines Interfaces in einem FIS findet daher kein Failover statt, solange noch ein Interface des FIS verfügbar und verbunden ist. Alle Schnittstellen, die nicht Teil eines Failover Interface Set sind und auf denen der HA Monitor nicht deaktiviert ist, sind sogenannte Critical Interfaces.