Loadbalancer mit VMWare

Manchmal fragt ein Kunde nach, ob der Loadbalancer, der für Exchange brav seine Dienste verrichtet, auch noch für andere Dienste benutzt werden kann. Oft geht es z.B. Um Anfragen von Routern an Radius-Server oder LDAP-Anfragen von Scannern, SMTP-Versand von Skripten, die alle nicht mit DNS-Round umgehen können, nur einen Server als Konfiguration zulassen oder keine Queue vorhalten um im Fehlerfall eines Servers eine Alternative zu nutzen. In diesen Fällen muss man sich genau die Anforderungen des verwendeten Protokolls anschauen und überlegen, wie man mit einem Loadbalancer die Verbindungen sinnvoll auf die mehrfach vorhandenen Servern verteilt.

So passiert bei einem Kunden, der eine VMWare View Farm betreiben will. Schön ist es natürlich, wenn der Hersteller des Loadbalancer bereits Erfahrung mit dem Protokoll hat und vielleicht Konfigurationshinweise liefern kann oder es im Loadbalancer sogar schon fertige "Templates" gibt. Aber selbst dann sollte man lieber zweimal nachschauen, denn oft ändern sich die Einstellungen mit einer neueren Version. Exchange Administratoren können das Problem mit der Veröffentlichung von Exchange OWA-Farmen über TMG, bei denen sich URLs und Cookies ändern und die Bedeutung der Clientzuordnung sich auch einmal ändern kann. Selbst wenn ein Anbieter z.B. Windows NLB vorschlägt, ist das noch keine Garantie, dass ein Loadbalancer die Dienste besser verteilen kann.

Also steht Grundlagenforschung an, um die Anforderungen bezüglich der Netzwerkprotokolle zu verstehen um zwei oder mehr VMWare View 5 Security Server oder VMWare View 5 Connection Server mit einem Loadbalancer richtig verfügbar zu machen und idealerweise noch die Last zu verteilen.

Hinweis:
Wer nur zwei Server bereitstellt, für den ist "Lastverteilung" eher sekundär da er beim Wegfall eines Systems (geplant/ungeplant) das verbleibende System 100% der Last bedienen muss. Hier kommt einem Loadbalancer mehr die Erhaltung der "Verfügbarkeit" zu. Es kann sogar gewollt sein, dass alle Verbindungen auf einem System landen und nur im Fehlerfall auf das andere System geschwenkt wird. Das macht dann auch die Fehlersuche einfacher.

Basisfunktion VMWare View

VMWare View bietet Clients den Zugriff auf eine „persönliche VM“ als Arbeitsplatz, z.B. von einem ThinClient. Dazu gibt es ein oder mehrere VMware-Server auf denen die VMs laufen und ein oder mehr VMWare Connection Server, die als Broker den Zugriff der Clients auf den jeweiligen VMWare Server verteilen. für einen gesicherten externen Zugriff gibt es gesonderte VMWare Security Server, die als Gateway arbeiten und z.B. eine Vorauthentifizierung erlauben. Zur Steigerung der Verfügbarkeit und Lastverteilung sind Loadbalancer an zwei Stellen von Vorteil:

  1. Verteilung der Zugriffe auf zwei oder mehr Security Server
    Dazu wird der Loadbalancer üblicherweise hinter einer Firewall vor die Security-Server geschaltet und verteilt Zugriffe von Extern auf eine virtuelle IP auf die Security Server. Die Security-Server ihrerseits geben dann die Daten in einer 1:1 Beziehung an die internen Connection Server weiter. Auf dieser Verbindung ist kein LB mehr vorzusehen.
  2. Verteilung von Zugriffen auf die internen Connection Server
    Interne Clients sprechen ebenfalls idealerweise eine virtuelle IP intern an, die durch einen internen LB auf die Connection Server verteilt wird.

Die Zuordnung der Security Server zu den Connection Server von extern nach intern ist eine 1:1 Verbindung. Daher steht der zweite Loadbalancer entsprechen intern zwischen den internen Client und dem Connection Server. Intern ist in der Regel keine Vorauthentifizierung gewünscht. Es ist aber durchaus möglich, auch die internen Clients über den Security Server zu routen.

Wer also sowohl intern als auch extern die Zugriffe verteilen will, muss an beiden Stellen die Funktion "Lastverteilung" umsetzen. Natürlich kann ein Loadbalancer auch mit je einem Bein in jedes Subnetz platziert werden und Zugriffe auf das eine Bein gezielt zu einem anderen System geben. Allerdings werden die meisten Firewall-Administratoren das nicht so gerne sehen, dass ein weiteres System die verschiedenen Firewall-Zonen überbrücken kann.

Für die Verbindung der Clients gibt es zwei relevante Betriebsarten

  1. TunnelMode (für Verbindungen aus dem Internet aber auch intern nutzbar)
    Dabei packt der Client alle Zugriffe in HTTPS ein. (RDP over HTTPS). Es wird nur 443 genutzt
  2. Bypass (nur intern)
    Der Client verbindet sich zwar noch per HTTPS mit dem Connection Server aber die Verbindung zur VM wird dann direkt hergestellt (RDP und einige andere Ports). RDP (3389 TCP), USB-Redirect (32111), MMR (9427)

Die Ports und Protokolle sind für den LB natürlich von Belang.

Extern zum Security Server

Um VMWare View "sicher" aus dem Internet erreichbar zu machen, empfiehlt sich neben einer guten Firewall der Einsatz der VMWare View Security Server. Extern Anwender "surfen" diese Adresse an und müssen sich erst einmal authentifizieren. Dabei können auch starke Verfahrung (Token etc.) eingesetzt werden. Erst wenn der Anwender erfolgreich identifiziert ist, werden seine Daten auf den Connection Server intern weiter gegeben. Sobald Verfügbarkeit oder Lastverteilung gefordert sind, sind zwei oder mehr dieser Server erforderlich. Nach Extern wird aber nur ein Name veröffentlicht. DNS-Round-Robin scheidet aus, das der Client beim Ausfall eines Servers nicht alleine die weiteren IP-Adressen "versucht". Lync macht das eleganter. DNS-Failover oder IP-Failover wäre eine Option aber dauert zu lange und erfordert eventuell einen manuellen Eingriff. Ein Pärchen Loadbalancer ist natürlich prädestiniert, von extern über eine virtuelle IP-Adresse angesprochen zu werden und die Verbindungen auf die nachgelagerten Security Server weiter zu geben:

Thema Einstellung Beschreibung

Protokoll

HTTPS
443/TCP

Hier ist für den Loadbalancer nur HTTPS/443 relevant. für die Phase 1 muss der Client über eine virtuelle IP auf jeden Fall auf einem funktionierenden Security Server landen. Das ist eine Aufgabe des Loadbalancer.

Layer4 ist ausreichend, wenn Source-IP ausreichend „unterschiedlich“ zur Clientunterscheidung sind. (nicht nutzbar, wenn alle Clients mit der gleichen Source-IP ankommen würden, weil die Firewall SourceNAT macht oder die Client hinter NAT sind oder alle Clients über den gleichen Reverse-Proxy kommen.

Layer7 mit SSLOffloading möglich. (SSL-Last vom Security Server wegnehmen, Cookie statt ClientIP nutzbar)

Sekundäre Connections

Keine

Nach erfolgter Authentifizierung startete die Phase 2. Der Securityserver teilt dazu dem Client einen DNS-Namen mit, über den der Tunnel aufgebaut wird. Das kann der gleiche Name wie für Phase 1 ein. In dem Fall muss der LB sicherstellen, dass diese zweite Connection des Client wieder beim gleichen Security Server landet.

Der Security Server kann dem Client aber auch einen anderen Namen mitteilen (External URL), der direkt auf den gleichen Security Server verweist. Die Tunnelverbindung kann damit den Loadbalancer umgehen oder auf eine zweie VIP des LB verweisen, der die Verbindungen zu dem bestimmten Security Server leitet.

Health Monitoring

HTTPGet

Idealerweise Überprüfung der HTTPS-Funktion. VMWare schlägt einen  „GET /favicon.ico“ vor. Das kann der Kemp Alternativ könnten die Services über das AJP13-Protokoll verifiziert werden, das kann KEMP (noch) nicht aber der http-Check ist vergleichbar gut

Persistence
Stickyness
Affinity

L4: Source-IP
L7: Authentication oder JSESSIONID-Cookie

Persistence bis VMWare View 4: Source-IP einzige Option mit bekannten Einschränkungen (Clients hinter NAT, Firewall SNAT etc.)

Ab VMWare 5: Aber VMWare View 5 wird im HTTP-Datenstrom auch ein Cookie (JSESSIONIP) bereit gestellt, über den der Loadbalancer den Verkehr lenken kann. Dazu muss er natürlich in den HTTPS-Datenstrom reinschauen.

Timeout

1 Stunde ?

Wenn ein Client eine Stunde nicht mehr mit dem Server kommuniziert, würde ich die Ressourcen auf dem Loadbalancer wieder frei geben. Hier müssen Sie aber selbst abwägen.

Es gibt also nicht genau eine Konfiguration, sondern es hängt auch davon ab, wie Sie VMWare View konfigurieren. Wer mit einer öffentliche IP-Adresse auskommen will, sorgt dafür, dass Clients immer zum gleichen Security Server kommen. Die Security Server müssen per "ExternalURL" den Client auch für die Folgeverbindungen (Phase 2) auf den Loadbalancer lenken

Wer die Verbindungen der Phase 2 um den Loadbalancer herum leiten möchte, muss jedem Security Server über eine eigene öffentliche IP-Adresse und mit einem eigenen Namen erreichbar machen. Der Loadbalancer bedient dann nur die Phase1-Verbindung bis der Client angemeldet und dann umgelenkt wurde.

Intern zum Connection Server

Die zweite Stelle für einen Loadbalancer ist die Verfügbarkeit der internen Connection Server zu erhöhen. Auch hier werden zwei oder mehr Server bereit gestellt, die aber vom Client unter einem Namen erreichbar sein sollen. VMWare spricht selbst davon, dass dies auch per NLB erfolgen kann aber ich rate von NLB ab, (Siehe auch NLB vs. HLB). Auch DNS-Round Robin fällt aus, wenn der Client nicht sinnvoll damit umgehen kann.

Für die Verbindung von internen Client zum Pool der Connection-Server kommt ebenfalls HTTPS als Phase 1 zum Einsatz. Es gelten die gleichen Voraussetzungen wie bei der Verbindung von Extern zum Security Server“. Wenn Source-IP als Session-Identifikation reicht, dann ist dies einfach möglich. Es kann aber auch hier die JSESSIONID genutzt werden, wenn der HTTPS-Traffic auf dem LB terminiert wird.

Wenn auch bei der Phase 2 der HTTPS-Tunnel eingesetzt wird, dann gelten die gleichen Anforderungen wie beim externen System. Wird für die Phase 2 aber Bypass gewählt, dann nimmt der Client direkt einen RDP-Verbindung zum VMWare View Host auf. In den meisten Firmen wird dies aber unterbunden, da ein Client dann auch unter Umgehung der VMWare View Connection Server sich direkt mit „seiner“ Workstation verbinden könnte. Die erhöhte Sicherheit erkauft man sich natürlich mit einer höheren Last auf den Connection Servern und mehr Connections auf dem Loadbalancer.

Thema Einstellung Beschreibung

Protokoll

HTTPS
443/TCP

HTTPS-Offloading Es ist möglich, die HTTPS-Verbindung des Clients auf dem Kemp zu terminieren. Dann kann der Kemp anhand des Cookies „JSESSIONID“ den Client unterscheiden. Dies hat den Vorteil, dass man auch mehrere Clients hinter der gleichen IP-Adresse (z.B. hinter einen NAT-Router oder wenn die vorgelagerte Firewall die SourceIP ersetzt) unterscheiden kann. Dann ist allerdings erforderlich, dass auch Folgeverbindungen korrekt zugeordnet werden.

Sekundäre Connections

RDP und andere

 

Health Monitoring

HTTPGet

Natürlich sollte ein Loadbalancer die Erreichbarkeit des backends möglichst realitätsnah prüfen. Ein ICMP-Ping ist „billig“ aber nicht aussagekräftig. Empfohlen ist hier der Test einer Webseite, die per HTTPS erreicht werden kann.

Persistence
Stickyness
Affinity

L4: Source-IP
L7: Authentication oder JSESSIONID-Cookie

 

Timeout

1 Stunde ?

 

Weitere Quellen

Wer geschickt im Internet sucht, findet sehr viele Informationen zu VMWare View und Loadbalancer. So gibt es Whitepaper von F5 und Cisco, Videos von VMWare und diverse Blogs. Allerdings muss man schon genau hinschauen und die Quellen prüfen, da sie vielleicht eine ältere Version beschreiben oder nur einen Teilaspekt beleuchten.

It’s important to select sourceip für persistence. The time-out of 5 minutes is important because I noticed the connection to the connection/security server will time out when the default of 2 minutes is used. It seems that there is a keep-alive to the connection/security server every 3 or 4 minutes or so. When setting this to 5 minutes on the load balancer, you don’t have to re-authenticate when you want to switch desktops or connect USB-devices.
Quelle: VMware KB 1032661  http://kb.vmware.com/kb/1032661

Führt explizit als „Lösung“ bei dem TunnelFehler den Wechsel der Affinity auf „Source-IP“ auf FC: Das gilt aber für VMWare View 3 und 4, die konnten noch nichts anderes, da im HTTPS-Header kein Cookie drin wäre

  • NLB
  • NLB vs. HLB
  • VMware View in general”
    http://youtu.be/Lk5Fz8vuPXo
    Sehr nette Beschreibung, auch wenn man etwas vorspulen kann.
  • Load balancing VMware View Security servers
    http://youtu.be/ZsRB7XMp29A
  • Load Balancing VMware View 4.5 with Microsoft NLB
    http://vstorage.wordpress.com/2010/09/20/load-balancing-vmware-view-4-5-with-microsoft-nlb/
    Ist aber nicht die aktuelle Version (5.0). Aber da sieht man gut, dass NLB einfach nur „ANY“ port nutzt und sie „Affinity“ auf die SourceIP macht (Bild http://vstorage.files.wordpress.com/2010/09/portrules.jpg?w=640 steht hinten „SINGLE“  für SingleIP. Das heisst aber, dass alle Verbindung „von“ dieser SingleIP eben als „ein Client“ gewertet werden. Auch wenn VMWare View 5 auch SSL mit JSESSIONID zulässt, kann ich mir gut vorstellen, dass auch der „alte Weg“ mit SourceIP weiter erlaubt ist. Wenn es beim Kunden möglich ist, ist es sogar „billiger“ (Ressourcen) als SSL offloading
  • Free VMware View Load Balancer using SUSE Studio and HAProxy
    http://vmtoday.com/2012/09/free-vmware-view-load-balancer-using-suse-studio-and-haproxy/
    Beispiel mit HAProxy. (was ein sehr einfacher Linux-basierter Loadbalancer ist.
  • http://virtualfuture.info/2012/02/free-load-balancing-for-vmware-view-with-citrix-netscaler-vpx-express/
    A load balancer provides that functionality but is often expensive and gives additional functionality not needed für smaller deployments, like SSL Offloading. There is however a free “Enterprise-ready” load balancer available from Citrix: Netscaler VPX Express. There is a 5 Mbit throughput limit, but that is not an issue and in this article I explain why. ..in most cases für the vCenter to be high available because Users can connect to a virtual desktop once the View agent in the virtual desktop has been registered to a VMware View connection server.. ..To be able to connect to a virtual desktop a VMware View Connection server needs to be available. It is highly recommended to have at least two connection servers in a VMware View Infrastructure. It doesn’t matter to which connection server a User connects to, the configuration is the same and stays the same because of the LDAP replication taking place between all the connection servers…
  • Cisco Solutions für a VMware View 4.0 Environment Design Guide
    http://bit.ly/8sC9RY
    http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/vmware/cisco_VMwareView.html
    One common approach to maintaining session persistence with VMware View is to use Source IP sticky. While Source IP sticky is not ideal, especially für Internet-based clients, it is generally all that can be used with VMware View 3.0 and 4.0. Cisco recommends using another form of persistence such as a cookie or JSessionID, but VMware View does not support this functionality.
  • F5 (http://www.f5.com/pdf/white-papers/dell-f5-vmware-view-wp.pdf)
    Interessanterweise schreibt F5, dass man den JSESSIONID-Cookie verwenden kann (vermutlich geht das seit VMWare View 5). Das heißt aber nicht, dass SourceIP nicht auch ausreichend wäre, wenn diese für eine Lastverteilung eindeutig genug sind.