In diesem Beitrag möchte ich eine Lösung vorstellen, mit der es möglich ist, ein Loadbalancing für VMware Horizon View Connection Server bzw. auch für View Security Server zu realisieren. Es gibt diverse unterschiedliche Lösungsansätze am Markt, ich möchte euch heute die Lösung von loadbalancer.org vorstellen. Warum diese Lösung?
- reines Loadbalancing, losgelöst von anderen Technologien
- einfaches Deployment (innerhalb von 1-2 Stunden)
- grafische Weboberfläche
- als virtuelle Appliance verfügbar
(Physik ist „böse“ und verbraucht nur Platz und Strom, virtuelle Appliances starten sich auf einem VMware vSphere HA Cluster automatisch bei Hardwareausfall neu) - trotzdem die Möglichkeit (wenn Bedarf) zu „clustern“
- Eval-Zeitraum möglich, um vorab zu testen
- offizieller Support vom Hersteller
- kostengünstig (ab 1.195,-€ beim Reseller des Vetrauens zu erhalten 😉 )
In den folgenden Absätzen möchte ich das Deployment und die Konfiguration für ein Loadbalancing per Loadbalancer.org Enterprise VA R16 von zwei internen View Connection Servern erläutern.
HINWEIS: Sollte die Appliance in mehreren Netzen (1 Beinchen „external“, 1 Beinchen „internal“) zum Einsatz kommen, sind evtl. weitere Konfigurationsschritte notwendig.
- Download der Appliance (ZIP-Datei entpacken)
- Appliance über vSphere Client deployen
- Name für VM vergeben
- Cluster auswählen
- passenden Datastore auswählen
- entsprechendes Netzwerk auswählen (entspricht eth0 der Appliance, sollte die Verbindung zu den Connection Servern bzw. Security Servern darstellen)
- Appliance nach dem Deployment direkt einschalten lassen. Appliance bootet
- auf der Console der Appliance mit Logon: setup und Passwort: setup den Basiskonfigurationswizard starten
- IP (Managementadresse für die Appliance), Subnetzmaske, Gateway, DNS Server vergeben und bestätigen
- auf die Weboberfläche der Appliance aufwählen (https://IPADRESSE:9443) und mit Logon: loadbalancer und Passwort: loadbalancer anmelden
- Startup Wizard ausblenden
- Hostname und DNS unter „Local Configuration“ – „Hostname und DNS“ prüfen
- Netzwerkeinstellungen unter „Local Configuration“ – „Network Interface Configuration“ prüfen
- Gateway unter „Local Configuration“ – „Routing“ prüfen
- Zeit unter „Local Configuration“ – „System date & time“ konfigurieren
- Standardkennwörter unter „Maintenance“ – „Passwords“ – „Modify“ ändern
- neuen virtuellen Service über „Cluster Configuration“ – „Layer 4 – Virtual Services“ – „Add a new Virtual Service“ wie angegeben anlegen (wichtig: Virtual Service IP Adress „1“ und „Firewall Marks“ -> Service erhält Firewallregeln mit dem Mark „1“ – siehe weitere Schritte)
- über „Modify“ einen Testport für den virtuellen Service konfigurieren, über den die Appliance prüft, ob die realen Server erreichbar und verfügbar sind (im Beispiel Port 80)
- über „Cluster Configuration“ – „Floating IPs“ die virtuelle IP vergeben, zu der sich die View Clients verbinden sollen (an Stelle der IP der Connectionserver direkt)
- unter „Maintenance“ – „Firewall Scripts“ die virtuelle IP vergeben (VIP1=x.x.x.x = angegebene Floating IP aus letztem Schritt), sowie die Firewallregeln für View anlegen (–set-mark 1 = gilt für Virtual Service mit der 1 – siehe „Add a new virtual service“ Step)
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
# Example: Associate HTTP and HTTPS with Firewall Mark 1: VIP1="VIRTUALIP" # External Client Connect over port 80 iptables -t mangle -A PREROUTING -p tcp -d $VIP1 --dport 80 -j MARK --set-mark 1 # External Client Connect over port 443 iptables -t mangle -A PREROUTING -p tcp -d $VIP1 --dport 443 -j MARK --set-mark 1 # RDP traffic iptables -t mangle -A PREROUTING -p tcp -d $VIP1 --dport 3389 -j MARK --set-mark 1 # PCoIP traffic iptables -t mangle -A PREROUTING -p tcp -d $VIP1 --dport 4172 -j MARK --set-mark 1 iptables -t mangle -A PREROUTING -p udp -d $VIP1 --dport 4172 -j MARK --set-mark 1 # MMR traffic iptables -t mangle -A PREROUTING -p tcp -d $VIP1 --dport 4972 -j MARK --set-mark 1 # View Client 4.5 und frueher iptables -t mangle -A PREROUTING -p tcp -d $VIP1 --dport 50002 -j MARK --set-mark 1 iptables -t mangle -A PREROUTING -p udp -d $VIP1 --dport 50002 -j MARK --set-mark 1 # HTML Access traffic iptables -t mangle -A PREROUTING -p tcp -d $VIP1 --dport 22443 -j MARK --set-mark 1 |
- alle zu loadbalancenden Connection Server als „Real Server“ über „Cluster Configuration“ – „Layer 4 – Real Servers“ – „Add a new Real Server“ hinzufügen
- Konfiguration des Loadbalancers ist abgeschlossen (erweiterte Erläuterungen zu meinen Screenshots und mehr Details finden sich im Guide
Load Balancing VMware View 5.x – Quick Reference Guide
- Unter Windows 2000, 2003, 2008 und 2012 muss ein Loopback Adapter an jedem Connection Server hinzugefügt werden, damit diese den Traffic der virtuellen IP akzeptieren. In den folgenden Screenshots sind die notwendigen Schritte für Windows 2008 beschrieben. Detailiertere Infos zu den anderen Betriebssystemen finden sich im Loadbalancer.org Appliance Quick Start Guide im Absatz „Resolving ARP issues for Windows Servers„
- über den „hddwiz“ einen Microsoft Loopbackadapter hinzufügen
- dem neuen Netzwerkadapter den Namen „loopback“ geben, in den Eigenschaften lediglich TCP/IPv4 aktivieren und die virtuelle IP-Adresse und Subnetzmaske des Loadbalancers angeben
- Namen der Netzwerkverbindungen notieren und in einer cmd mit den entsprechenden „netsh“ Befehlen die Einstellungen für ein funktionierendes Loadbalancing setzen
|
1 2 3 |
netsh interface ipv4 set interface "LAN-Verbindung" weakhostreceive=enabled netsh interface ipv4 set interface "loopback" weakhostreceive=enabled netsh interface ipv4 set interface "loopback" weakhostsend=enabled |
- diese Schritte auf allen zu loadbalancenden Connection Servern wiederholen
- mit dem View Client bzw. per HTML Access testen, ob der Loadbalancer funktioniert (bei der Eingabe des Connection Servers die virtuelle IP des Loadbalancers angeben)
- wie das Loadbalancing die Last verteilt, kann in der Weboberfläche der virtuellen Appliance unter „Reports“ – „Layer 4 Status“ und „Reports“ – „Layer 4 Traffic Rate“ eingesehen werden
– I wish I could be a Virtual Machine –
Benjamin Ulsamer
Senior Consultant & Trainer
teamix GmbH
Benjamin Ulsamer
Benjamin Ulsamer ist seit Januar 2011 für die Firma Proact Deutschland GmbH tätig. Er startete als Senior Consultant & Trainer und war Teamlead im Bereich Virtualisierung. Im Oktober 2015 wurde er zum Manager Professional Services Region South ernannt. Seit Juni 2017 ist er verantwortlich für die IT-Ausbildung. In den Jahren 2015, 2016 und 2017 hat er für sein Engagement bzgl. Blogging & Wissensvermittlung von VMware die Auszeichnung zum vExpert erhalten. Seit 2021 ist er zudem mit verantwortlich für das Marketing von Proact.
Super Artikel, sehe leider zu oft Microsoft NLB oder DNS Round Roubin in Horizon View Umgebungen. Schon Erfahrungen mit dem Zen Load Balancer gesammelt?