AWS Citrix Netscaler HA Solution

Citrix Netscaler hochverfügbar innerhalb von AWS Umgebungen bereit zu stellen, klingt wenig kompliziert und auf den ersten Blick einfach umzusetzen. Und doch war das in der Vergangenheit gar nicht so einfach.

Warum?

Eine HA Lösung in AWS aufzubauen ist an sich recht einfach durch die Nutzung von AWS Autoscaling.

Grundlegende Voraussetzung dafür ist jedoch , dass die Instanzen selbst stateless sind, dynamische Konfigurationen und Loging Daten an einer zentralen Stelle gespeichert werden (S3 Buckets) und das die AWS API nativ von den Instanzen genutzt werden kann.

Lange Zeit erfüllten die VPX Image Versionen, welche über den AWS Market Place bereit gestellten wurden, keine der oben genannten Bedingungen. Viele Kunden beschränkten sich daher auf die Bereitstellung der Netscaler im Single Mode.

Dabei bieten die Netscaler selbst die integrierten Funktionalitäten um HA Lösungen aufzubauen.
Was also in klassischen Rechenzentren schon immer funktionierte, erwies sich in AWS Umgebungen als großes Problem.

Und? Gibt es eine Lösung?

Die gute Nachricht lautet ja.

Citrix hat mittlerweile nachgebessert und in den aktuellen VPX Images aus dem AWS Market Place wurde die AWS API Call Funktionalität implementiert.

Stateless sind diese Instanzen jedoch immer noch nicht, da diese Ihre Konfigurationen noch immer nicht an S3 Buckets übertragen können.

Ein HA Aufbau funktioniert also heute durch folgende Kombination.

Es werden die internen VPX HA Funktionen in Verbindung mit den AWS API Calls genutzt.

Der Aufbau

Architekturbeispiel:

Bereitstellung der VPX Instanzen mit 3 Netzwerk Interfaces

Im Standard werden die VPX Instanzen mit 3 Netzwerk Schnittstellen betrieben.

— Management Schnittstelle zur Konfiguration der Netscaler selbst, hier ETH/0.

— Client Schnittstelle für den Zugriff aller externen Zugriffe, hier ETH/1

— Server Schnittstelle für die Übergabe Traffic Client Interface an die Backend Systeme, hier ETH/2

ETH/1 und ETH/2 werden in AWS als ENI (Elastic Network Interface) bereit gestellt und zusätzlich an die VPX Instanz gebunden.

Bereitstellung Instanzprofil (IAM Role) für VPX Instanzen

Die IAM Rolle an den VPX Instanzen wird benötigt um die AWS API Funktion nutzen zu können.

Mit Hilfe der übergebenen Berechtigungen, können die Netscaler Ihren Status innerhalb der AWS Umgebung ermitteln und noch viel wichtiger, Sie können sich die benötigte Elastic IP zuweisen, im Fail over Fall.

Notwendige Berechtigungen:

"Effect": "Allow",
            "Action": [
                   "ec2:DescribeInstances",
                   "ec2:DescribeNetworkInterfaces",
                   "ec2:DetachNetworkInterface",
                   "ec2:AttachNetworkInterface",
                   "ec2:StartInstances",
                   "ec2:StopInstances",
                   "ec2:RebootInstances",
                   "ec2:DescribeAddresses",
                   "ec2:AssociateAddress",
                   "ec2:DisassociateAddress",

Bereitstellung einer Elastic IP Adresse

Elastic IP Adressen sind bekanntlich öffentlich persistente IP Adressen.

Wir binden die EIP an das Client ENI_1 der ersten Netscaler Instanz.

Wichtig dabei:

EIP nicht an die Instanz binden, sondern wirklich an das Network Interface und die zugewiesene interne private IP Adresse den Netzwerk Interface mit übergeben.

IPSet auf den Netscaler Instanzen erstellen

IPSet entspricht von der Logik her, dem HSRP Konstrukt von Cisco.

IPSet wird auf den beiden Netscalern konfiguriert. Hierbei werden virtuelle IP Adressen, je eine pro ClientENI erzeugt und diese werden der EIP im IPSet zugewiesen.

Security Gruppen VPX Instanzen

Die beiden VPX Instanzen benötigen zum Austausch Ihrer internen Events, Health Checks folgende Kommunikationsports:

— TCP 0-6550
— UDP 3000 – 3010

Gebunden wird diese Security Gruppe an das ETH/0 (Management Netzwerk Interface)

Was passiert nun im Fail over Fall?

Im Falle eines Fehlers auf dem primären Netscaler wird nun die AWS API Funktionalität auf dem 2. Netscaler genutzt um die EIP vom ClientENI 1 auszulesen um diese dann dem ClientENI 2 (2. Netscaler) zu zuweisen.

Dieser Vorgang dauert weniger als 20 Sekunden, Nutzer Session überleben den Fail over ohne Probleme und brechen nicht ab.