WebSphere Load Balancer for IPv4 and IPv6
             Betriebssysteme: AIX, HP-UX, Linux, Solaris, Windows

             Inhaltsverzeichnis und Suchergebnisse personalisieren

Problem: Einschränkungen für die Dispatcher-Konfiguration unter Linux auf zSeries- oder S/390-Servern mit OSA-Karten

Die Server der Load-Balancer-Konfiguration müssen sich generell und unabhängig von der Plattform in einem Netzsegment befinden. Aktive Netzeinheiten wie Router, Brücken und Firewalls behindern Load Balancer. Dies liegt daran, dass Load Balancer wie ein spezialisierter Router funktioniert, der nur die Header der Verbindungsschicht für seinen nächsten und letzten Hop modifiziert. Jede Netztopologie, bei der der nächste Hop nicht der letzte Hop ist, ist für Load Balancer nicht gültig.
Anmerkung: Tunnel wie CTC (Channel-To-Channel) oder IUCV (Inter-User Communication Vehicle) werden oft unterstützt. Die Weiterleitung von Load Balancer muss jedoch durch den Tunnel direkt zum Zielort erfolgen. Es darf sich nicht um einen Tunnel zwischen Netzen handeln.

Für zSeries- und S/390-Server, die die OSA-Karte gemeinsam nutzen, gibt es eine Einschränkung, weil dieser Adapter anders als die meisten Netzkarten funktioniert. Die OSA-Karte hat eine eigene virtuelle Implementierung der Verbindungsschicht, die nichts mit dem Ethernet zu tun hat, das sich den Linux- und z/OS-Hosts präsentiert. Die Verbindung über eine OSA-Karte sieht tatsächlich wie eine Verbindung zwischen Ethernet-Hosts (und nicht wie eine Verbindung zu OSA-Hosts) aus, und die Hosts, die eine solche Karte verwenden, behandeln sie wie eine Ethernet-Karte.

Die OSA-Karte führt auch einige Funktionen mit direktem Bezug zur IP-Schicht aus. Eine ihrer Funktionen ist beispielsweise die Beantwortung von ARP-Anforderungen (Address Resolution Protocol). Außerdem leitet die gemeinsam genutzte OSA-Karte IP-Pakete ausgehend von der Ziel-IP-Adresse weiter und nicht wie ein Switch der Schicht 2 ausgehend von der Ethernet-Adresse. Eigentlich ist die OSA-Karte ein Netzsegment mit einer Brücke zu sich selbst.

Wird Load Balancer auf einem S/390- oder zSeries-Host mit Linux ausgeführt, können Pakete an Hosts mit derselben OSA-Karte oder an Hosts im Ethernet weitergeleitet werden. Alle Hosts, die dieselbe OSA-Karte gemeinsam benutzen, befinden sich effektiv im selben Segment.

Die Natur der OSA-Brücke versetzt Load Balancer in die Lage, Pakete aus dem Bereich der gemeinsam genutzten OSA-Karte hinaus weiterzuleiten. Der Brücke ist der OSA-Port bekannt, der Eigner der Cluster-IP-Adresse ist. Außerdem kennt die Brücke die MAC-Adresse von Hosts, die direkt mit dem Ethernet-Segment verbunden sind. Deshalb kann Load Balancer über eine OSA-Brücke Datenpakete mit der Weiterleitungsmethode "mac" weiterleiten.

In den Bereich einer gemeinsam genutzten OSA-Karte hinein kann Load Balancer jedoch keine Daten weiterleiten. Dies gilt auch für Load Balancer auf einem S/390 mit Linux, wenn der Back-End-Server eine andere OSA-Karte als Load Balancer verwendet. Die OSA-Karte für den Back-End-Server macht die OSA-MAC-Adresse für die Server-IP-Adresse zugänglich. Wenn jedoch ein Paket mit der Ethernet-Zieladresse der Server-OSA-Karte und der IP-Adresse des Clusters ankommt, weiß die OSA-Karte des Servers nicht, welche Hosts das Paket ggf. empfangen sollten. Die Prinzipien, die zwischen OSA und Ethernet eine Weiterleitung mit der Methode MAC bei einer gemeinsam genutzten OSA-Karte möglich machen, gelten nicht, wenn versucht wird, Daten in den Bereich einer gemeinsam genutzten OSA-Karte hinein weiterzuleiten.

Problemumgehung:

In Load-Balancer-Konfigurationen mit zSeries- oder S/390-Servern, die OSA-Karten enthalten, gibt es zwei Möglichkeiten, das oben beschriebene Problem zu umgehen.
  1. Verwendung von Plattformfeatures

    Falls die Server der Load-Balancer-Konfiguration denselben zSeries- oder S/390-Plattformtyp haben, können Sie zwischen Load Balancer und den einzelnen Servern Punkt-zu-Punkt-Verbindungen (CTC oder IUCV) definieren. Konfigurieren Sie die Endpunkte mit privaten IP-Adressen. Die Punkt-zu-Punkt-Verbindung wird nur für den Datenverkehr zwischen Load Balancer und dem jeweiligen Server verwendet. Fügen Sie dann die Server mit der IP-Adresse des Serverendpunkts für den Tunnel hinzu. Bei dieser Konfiguration fließt der Clusterdatenverkehr über die OSA-Karte von Load Balancer und wird über die Punkt-zu-Punkt-Verbindung weitergeleitet. Der Server antwortet dann über seine eigene Standardroute. Die Antwort wird über die OSA-Karte des Servers abgesetzt. Dabei muss es sich nicht um dieselbe Karte handeln.

  2. Verwendung des Kapselungsfeatures von Load Balancer.

    Falls die Server der Load-Balancer-Konfiguration nicht denselben zSeries- oder S/390-Plattformtyp haben oder keine Punkt-zu-Punkt-Verbindung zwischen Load Balancer und den einzelnen Servern definiert werden kann, sollten Sie das Kapselungsfeature von Load Balancer verwenden. Das Kapselungsfeature ist ein Protokoll, mit dem Load Balancer Daten über Router weiterleiten kann.

    Wenn Sie Kapselung verwenden, wird das vom Client an die Cluster-IP-Adresse von Load Balancer gekapselt empfangen und an den Server gesendet. Auf dem Server wird das ursprüngliche Paket von Client an die Cluster-IP-Adresse entkapselt, und der Server antwortet dem Client direkt. Der Vorteil der Verwendung von GRE besteht darin, dass Load Balancer nur den Datenverkehr vom Client zum Server sieht, nicht aber den Datenverkehr vom Server zum Client. Der Nachteil ist, dass GRE durch den Kapselungsaufwand die maximale Segmentgröße der TCP-Verbindung herabsetzt.

    Im Artikel Kapselungsweiterleitung für die Weiterleitung von Datenverkehr über Netzsegmente verwenden finden Sie weitere Informationen zur Konfiguration von Load Balancer für die Weiterleitung mit Kapselung.



Nutzungsbedingungen | Feedback

Letzte Aktualisierung: 31. Juli 2008 3:18:06 PM EDT
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.edge.doc/lb/info/ae/ttrb_osalim.html