NetScaler String Maps

Ein Beispiel aus dem "echten Leben": Bestehende Reverse Proxies für eine öffentliche Website sollen abgelöst werden. Im Einsatz ist der Apache HTTP-Server mit mod_proxy, mod_rewrite und vhost-Konfigs im Bereich von über 100kb.

Diese 100kb bestehen fast ausschließlich aus RewriteRules, Redirects und ProxyPass Regeln. Sinn und Zweck ist hier, dass einerseits nur Pfade und URLs erreichbar sind, die explizit den Proxy passieren dürfen (ProxyPass Regeln als Positivliste), und andererseits regelmäßig von der Marketingabteilung in Umlauf gebrachte Kurz-URLs zu den vollständigen Pfaden plus Parametern aufgelöst werden, die die Webserver/-services dann auch gebrauchen und ausliefern können.

Eine an sich leichte Übung mit Content Switching Virtual Servern, Load Balancing Virtual Servern, Responder Policies (Redirects) und Rewrite Policies.

Zusätzlich könnte man noch ein Pattern Set als Positivliste schon im Content Switching VS einsetzen. Noch mal kurz drüber nachgedacht – das will doch aber keiner pflegen! Die bestehende Konfig ist über Jahre gewachsen, die Listen sind elend lang und hätten bei dieser Überführung riesige Listen von Policies zur Folge.

Die Lösung und enorme Erleichterung kam mit:

NetScaler Release 9.3: String Maps

Der Kunde bekommt: je Einsatzzweck (Redirect / Rewrite) eine String Map, in der jeweils die erwartete URL/Pfad (Schlüssel) und die daraus resultierende URL/Pfad für den Redirect respektive die Umschreibung (Wert) aufgenommen werden. Dann gibt es einen Content Switching VS, an den die Responder Policy (ja, nur genau eine!) gebunden wird. Diese Policy prüft (Expression), ob die aufgerufene URL/Pfad in der Redirect String Map enthalten ist. Falls ja, wird eine Responder Action vom Typ Redirect aufgerufen, in der wiederum das Ziel des Redirects aus der String Map gelesen wird.

Per Content Switching Policies werden die restlichen Requests auf die entsprechenden Load Balancing VS verteilt. Requests, die für keinen der LBVS passend sind (die Kriterien kann man nun doch wieder mit Pattern Sets oder einzelnen String Maps abbilden, wie es eben passt), landen in einem Catch-All LBVS oder einem direkten Redirect zu einer Startseite. An die LBVS wird dann jeweils genau eine Rewrite Policy gebunden, die wiederum per String Map das Rewriting der Kurz-URLs u.ä. vornimmt. In diesem Fall so aufgeteilt und nicht auch schon im CSVS, damit die einzelnen Maps kleiner sind – aber da das Vergleichen mit einer String Map um Größenordnungen schneller ist als das Durchackern hunderter Policies, könnte man das auch noch stärker zentralisieren.

Die Pflege dieses Setups beschränkt sich künftig auf das Ergänzen/Anpassen der String Map Einträge.

Kein Gefummel an Policies, wunderbare Übersicht.