NetScaler Loadbalancing – Storefront

Nachdem ich mich letzte Woche mit dem loadbalancen der Delivery Controller befasst habe gehe ich heute auf die Storefront-Server ein. Das Fallbeispiel basiert auf folgender Umgebung: StorefrontLB

Verwendeter LB Monitor: STOREFRONT

Auszug aus den Citrix Docs: “The monitor determines the state of the StoreFront store by successively probing the account service, authentication service, and discovery document (in that order). If any of those services do not respond to the probe, the monitor probe fails, and the StoreFront store is marked as DOWN. The monitor sends probes to the IP address and port of the bound service. Monitor probes originate from the NetScaler IP (NSIP) address. However, if the subnet of a StoreFront server is different from that of the appliance, then the subnet IP (SNIP) address is used.”

Das Monitoring-Script befindet sich unter /netscaler/monitors/nssf.pl

Meines erachtens ist die oben erwähnte Reihenfolge falsch dokumentiert (Discovery Document wird vor Auth Service geprüft) – hier der korrekte Verlauf des Scripts:

nssf-monitor_v2

Hierbei ist es entscheidend, welche Storefront-Version im Backend eingesetzt wird: Ab Stofrefront 3.x können alle einzelnen Storefront-Services geprüft werden:

Storefront Windows Service Monitor

Hierzu muss vorab der Citrix Monitoring Service auf den Storefront IIS-Port (443/80) gebunden werden:

Remove-DSServiceMonitorFeature 
Install-DSServiceMonitorFeature -ServiceUrl "https://localhost:443/StorefrontMonitor"
#bzw. für http:
Install-DSServiceMonitorFeature -ServiceUrl "http://localhost:80/StorefrontMonitor"

Danach lässt sich durch aufrufen der Site https://localhost/StorefrontMonitor/GetSFServicesStatus der Status der einzelnen Windows-Dienste einsehen (Zertifikatsfehler ggfs. ignorieren):
GetSFServiceStatus
Zeigt ein Dienst nicht den Status “Running” schlägt der Test fehl und der Server ist somit DOWN. In einer Server-Gruppe mit mehr als einem Storefront-Server wird diese Änderungen via “Propagate Changes” automatisch verteilt.

Wie bereits erwähnt ist dieses Feature erst ab Storefront 3.x verfügbar – für ältere Storefront-Versionen entfällt dieser Test.

Account Service

Wichtig vorab: Bei mandantenfähigen Umgebungen ist es ratsam diesen Test zu deaktivieren!

Wird bei der Konfiguration des Monitors kein Storename definiert wird der Standardwert “Store” verwendet.

Der NetScaler sendet einen http-get-Request an den jeweiligen Storefront-Server “/Citrix/Roaming/accounts”. Erhält er als Antwort “HTTP 401 – Unauthorized” wird zusätzlich geprüft, ob im Header “WWW-Authenticate” eine Antwort in Form eines gültigen Tokens geliefert wird.

AccountHeader

Dicovery Document

Als nächsten Punkt wird das Discovery-Dokument des Storefront-Servers unter
/Citrix/[Store]/discovery abgefragt.

DiscoveryHeader

Erhält der NetScaler als Anwort-Header Status “HTTP 200 – OK” und Content-Type “/vnd.citrix.receiver.configure” wird das erhaltene Discovery-Dokument geprüft:

  • Enthält es eine Adresse
    <Address>
    https://storefront.domain.local/Citrix/Store/discovery
    </Address>
  • Enthält es einen Auth-Endpoint
    <AuthEnd-point>
    https://storefront.domain.local/Citrix/Authentication/endpoints/v1
    </AuthEnd-point>
  • Enthält es einen Endpoint
    <End-point>
    https://storefront.domain.local/Citrix/Store/endpoints/v1
    </End-point>

Auth Service

Im letzen Schritt wird der aus obigem Discovery Document erhaltene Auth Service geprüft. Hierzu wird via HTTP-Post eine Anfrage an den Auth Service gestellt – gibt dieser eine gültige Antwort zurück ist auch dieser Test erfüllt und der Storefront Server gilt somit als UP.

Persistency

Anders als bei den Delivery Controllern benötigen wir für das loadbalancen der Storefront-Server eine Persistency. Vorab muss sichergestellt sein, dass die HTTP-Anfrage die IP des anfragenden Clients enthält. Dies wird durch den “X-Forwarded-For”-Header in der ServiceGroup erreicht:

X-Forwarded-For

Cookie Insert

Um nun sicherzustellen, dass die Anfrage eines Benutzers immer vom selben Storefront-Server beantwortet wird, wird auf vServer-Ebene die Persistency “COOKIEINSERT” gesetzt.

Hierbei setzt der NetScaler initial ein clientseitiges Cookie. Per Default hat dieses Cookie ein Timeout von 2 Minuten. Da dies in den wenigsten Fällen dem Session-Timeout der Storefront-Server entspricht ist es ratsam das Timeout auf “0” zu setzen – durch diesen Wert bleibt das Cookie solange erhalten, bis die Browser-Session geschlossen wird.

Der Verwendung von COOKIEINSERT hat den wesentlichen Vorteil, dass ab der zweiten Anfrage des Clients netscalerseitig nahezu keine Rechenleistung erforderlich ist.

Aufbau Cookie

Das Cookie hat den folgenden Aufbau:
<NSC_XXXX>= <ServiceIP> <ServicePort>

Cookie

<NSC_XXXX> = Die codierte vServer-ID, abgeleitet vom Namen des vServers.
Hier: NSC_wtfswfs-80-TUPSFGSPOU = NSC_vserver-80-STOREFRONT
<ServiceIP> = codierte IP(hex) des Servers
<ServicePort> = codierter Port(hex) des Servers

Durch ein wenig reverse Engineering lässt sich aus dem Cookie die interne Server-IP errechnen (siehe Quelle IT-Geek Chronicles). Um das Cookie später einfacher Tracen zu können benenen wir es in NSC_STOREFRONT_LB um:

Cookie

Verschlüsselung

Ab dem NetScaler-Release 10.5 build 55.8 ist es möglich, die obigen Cookie-Informationen mit einem Passwort zu verschlüsseln – die interne ServerIP ist somit nicht mehr aus dem Cookie rekonstruierbar.
Cookie_Encrypted

Backup Persistency

Sollte es nicht möglich sein ein clientseitiges Cookie zu Speichern empfielt sich eine Backup Persitency. Hier verwendet man üblicherweise die  SOURCE IP mit dem entsprechenden Timeout der Storefront-Session (default: 20min).

Implementierung

Für die Implementierung benötigen wir:

  • IP für LB vServer (hier: 10.0.1.224)
  • SSL-Zertifikat für LB vServer (hier: storefront.domain.local)
  • DNS-Eintrag für LB vServer (hier: storefront.domain.local)
  • Passwort zur Verschlüsselung des Cookies (hier: P@ssw0rd)

Wichtig: Dieses Fallbeispielt basiert auf der Verwendung von https!

Server hinzufügen

add server STOREFRONT01 10.0.1.210 -comment "\"Citrix Storefront Server\""
add server STOREFRONT02 10.0.1.211 -comment "\"Citrix Storefront Server\""

Monitor erstellen

add lb monitor monitor-STOREFRONT_3x STOREFRONT -scriptName nssf.pl -dispatcherIP 127.0.0.1 -dispatcherPort 3013 -LRTM ENABLED -secure YES -storename Store -storefrontcheckbackendservices YES -storefrontacctservice YES
add lb monitor monitor-STOREFRONT_2x STOREFRONT -scriptName nssf.pl -dispatcherIP 127.0.0.1 -dispatcherPort 3013 -LRTM ENABLED -storefrontacctservice YES -secure YES -storename Store

ServiceGroup erstellen

add serviceGroup serviceGroup-STOREFRONT SSL -maxClient 0 -maxReq 0 -cip ENABLED X-Forwarded-For -usip NO -useproxyport YES -cltTimeout 180 -svrTimeout 360 -CKA NO -TCPB NO -CMP NO
bind serviceGroup serviceGroup-STOREFRONT STOREFRONT01 443 -CustomServerID "\"None\""
bind serviceGroup serviceGroup-STOREFRONT STOREFRONT02 443 -CustomServerID "\"None\""
bind serviceGroup serviceGroup-STOREFRONT -monitorName monitor-STOREFRONT_3x

vServer erstellen

add lb vserver vserver-443-STOREFRONT SSL 10.0.1.223 443 -persistenceType COOKIEINSERT -timeout 0 -persistenceBackup SOURCEIP -backupPersistenceTimeout 20 -Listenpolicy NONE -cltTimeout 20
set lb parameter -useSecuredPersistenceCookie ENABLED -cookiePassphrase P@ssw0rd

Konfiguration Storefront

Im Storefront-Cluster muss die Base-Url auf den fqdn des neu erstellen LB-vServers geändert werden:

SF_BaseUrl

Verwendete Quellen:

Citrix Docs – NS11 HTTP Cookie Persistence
Citrix Support – Configuration of COOKIEINSERT Persistence on NetScaler
Koetzing.eu – Netscaler 11.x Monitoring von StoreFront 3.x Diensten
IT-Geek Chronicles – Netscaler: Making sense of the Cookie

Wie immer gilt:
Für Vollständigkeit, Fehler redaktioneller und technischer Art, Auslassungen usw. sowie die Richtigkeit der Inhalte wird keine Haftung übernommen. Umsetzung auf eigene Gefahr.

One thought on “NetScaler Loadbalancing – Storefront”

Leave a Reply

Your email address will not be published. Required fields are marked *