Seit kurzem darf ich mich als "Kemp Certified Consultant" bezeichnen. Gemeinsam mit Christian Lapacka war ich auf dem Zertifizierungstraining und kann jetzt behaupten ein wenig zu verstehen wie diese Load Balancer funktionieren.
Sie fragen sich was genau Kemp ist?
Nun ja, Kemp ist Hersteller für Hardware (Virtuelle) Load Balancer Systeme.
Im Prinzip gehts darum eine Applikation bzw. ein Service redundant zur Verfügung zu stellen und Zugriffe entsprechend auf mehrere Systeme dahinter zu verteilen. Interessant wird das vor allem für Services wie Exchange 2010 Client Access, Sharepoint oder Lync. Am Beispiel von Exchange wird zwar "offiziell" (siehe Load Balancing in TechNet) auch immer wieder davon gesprochen dass simples DNS Round-Robin genauso verwendet werden kann (Supported hin oder her..), aber das ist nun mal auch kein Load Balance und schon gar kein Failover. Es ist halt a bisschen von beidem und alles nur halb. Warum ist einfach erklärt (siehe KempTechnologies.com: MS Exchange 2013: Useful blog post about load balancing 2013 vs 2010).
DNS Round Robin reagiert nicht darauf ob ein Exchange-Server nicht mehr verfügbar ist, sondern schickt auch weiterhin Anfragen zum Server die dann halt nicht beantwortet werden. Man muss manuell eingreifen um den kaputten Exchange-Server aus dem DNS System zu entfernen. Passiert das nicht, werden Anfragen von Clients weiterhin auf das nicht verfügbare System geleitet. Es passiert kein "Health Check".
Genau da bietet ein wirklicher Load Balancer entsprechende Vorteile. Einerseits ist der Load Balancer selbst ein System - im Idealfall mit zwei Knoten -, das sich selbst überwacht und bei Ausfall eines Knotens entsprechend mit den verbleibenden Knoten übernimmt. Andererseits können die Load Balancer selbst überwachen ob die dahinterliegenden Systeme noch funktionieren.
Dadurch entscheidet der Load-Balancer selbst ob Anfragen auf ein System geschickt werden oder nicht. Im Fall von Kemp kann das auch auf unterschiedlichste Arten passieren. Bei einfachen Web Services natürlich durch HTTP GET / POST Anfragen deren Antwort entsprechend beantwortet werden. Komplexere Anfragen wie bei Terminal Services sind aber genauso möglich. Die Auslastung von CPU / Memory kann genauso interpretiert werden. Kleine Spielerein wie, Responsezeiten auf Requests als Entscheidungskriterium wohin die Verbindung geschickt werden soll, sind genauso möglich.
Warum ist das jetzt gerade für mich interessant? Einfach. Microsoft hat die Weiterentwicklung von Forefront Thread Management Gateway (TMG) eingestellt. Damit wird das Produkt zwar noch unterstützt, aber halt nicht mehr lange (siehe Microsoft Product Lifecycle Forefront Threat Management Gateway 2010)
Damit gilt es einen Ersatz zu finden. Ja - natürlich nicht sofort und auf der Stelle, aber man muss mal drüber nachdenken und schön langsam Alternativen suchen. Genau dafür bietet sich Kemp an. Nicht nur, weil es um Load Balancing geht, sondern auch, weil es speziell für den Ersatz von TMG ein eigenes Edge Security Pack gibt.
Per heute kann Kemp PreAuthentication und die Authentication weiter delegieren. Sehr eingeschränkt und zum Beispiel noch keine Kerberos Delegation, aber auch daran wird aktiv weiterentwickelt.
Als vollständiger TMG Ersatz ist es heute noch nicht zu 100% einsetzbar, aber es entwickelt sich in diese Richtung. Leider fehlen noch einige Funktionen die TMG so aus dem Ärmel geschüttelt hat. Vor allem gehts ja auch darum dass TMG extrem günstig und für den "Durchschnitts"-Windows Admin trotzdem bedienbar und verständlich war. Hier setzt Kemp an. Der Preis ist im Bereich der Load Balancer unschlagbar und weit unter dem Mitbewerb wie F5 oder Citrix Netscaler. Dennoch ist die Konfiguration durchaus durchschaubar und relativ einfach.
Jeder, der heute ein nervöses Zucken bekommt wenn man über das Thema Reverse Proxy spricht sollte sich Kemp mal ansehen oder einfach mal anrufen. Wir zeigen die Load Balancer gern im hauseigenen Testenvironment her und beraten gerne.
LG Christoph