Bessere Verfügbarkeit Ihrer Netzwerkverbindungen durch i5/OS virtuelle IP-Adressen

11. November 2008 | Von | Kategorie: Hochverfügbarkeit

Das Thema Verfügbarkeit gewinnt bei vielen Unternehmen immer mehr an Bedeutung. Hochverfügbarkeitslösungen, die sicherstellen, dass geschäftskritische Anwendungen bei Ausfall eines Produktionssystems durch Umschaltung auf ein Backup-System wieder schnell zur Verfügung stehen, sind schon vielfach im Einsatz. Dabei liegt der Fokus oft bei den Anwendungen, jedoch wird meistens ein wesentlicher Aspekt der Verfügbarkeit übersehen, nämlich der Netzwerkzugang zum System selbst.

Bessere Verfügbarkeit Ihrer Netzwerkverbindungen durch i5/OS virtuelle IP-Adressen


von Thomas Barlen

über den Autor

Thomas Barlen arbeitet für das IBM Systems and Technology Group Lab Services Team. Er tritt regelmäßig als Sprecher bei internationalen Konferenzen auf und arbeitet in Kundenprojekten im Bereich Sicherheit und Netzwerke. Herr Barlen ist zu erreichen unter barlen ät de.ibm.com

 

Im IBM System i Umfeld nutzen die meisten Unternehmen nur einen Ethernet-Adapter für den Zugang zum Netzwerk. Hunderte oder sogar tausende von Verbindungen von Endanwendern und anderen Systemen laufen über einen Netzwerkadapter. Wenn dieser Adapter ausfällt, ein Fehler im Kabel oder Switch auftritt, werden alle aktiven Sitzungen unterbrochen. Dabei ist es im IBM i (ehemals OS/400 oder i5/OS) Betriebssystem sehr einfach auch bei Ausfall eines Ethernet-Adapterports oder eines Kabels die Verfügbarkeit der aktiven Verbindungen zu gewährleisten. Die Funktionen, die hierfür verwendet werden, sind eine virtuelle IP-Adresse und ein weiterer Ethernet-Adapter.au2_look_IMG_0028_Z_nf_o

Grundlagen

Um zu verstehen, wie eine Ausfallsicherheit von Netzwerkverbindungen mit Hilfe von virtuellen IP-Adressen erreicht wird, möchte ich in diesem Artikel noch einmal ein paar Grundlagen erläutern. Als Beispielumgebung für diesen Artikel wird Folgendes angenommen:

  • IBM System i model 550 mit einem #5706 2-Port 1GB/100MB/10MB Ethernet Adapter
  • IBM i release V5R4 (5722-SS1)
  • Das System ist über Ethernet im lokalen IP-Netzwerk 192.168.2.0 / 24 über die Adresse 192.168.2.20 zu erreichen, welche als IP-Schnittstelle auf dem physischen Port 0 des Ethernet-Adapters konfiguriert ist. Der Ethernet-Adapter hat die Media Access Control Adressen: 00:09:6B:AE:AB:DC für Port 0 und 00:09:6B:AE:AB:DD für Port 1.

In diesem Beispiel stellt der Client WORK1 eine 5250-Telnet-Verbindung zum System PROD1 her. Folgende Schritte laufen dabei im Netzwerk ab:

  1. Der Client WORK1 sendet eine DNS-Anfrage für PROD1 an den DNS-Server.
  2. Der DNS-Server hat einen A-Resource-Record mit der IP-Adresse 192.168.2.20 und sendet dies als Antwort an den Client zurück.
  3. Der Client möchte nun wissen, wie er an das System mit der IP-Adresse 192.168.2.20 im Netzwerk gelangt. Dazu müssen Sie wissen, dass ein System im Ethernet-Netzwerk nicht direkt über die IP-Adresse, sondern nur über eine physische Adapteradresse (Media Access Control – MAC-Adresse) zu erreichen ist. Der Client sendet dazu eine Address Resolution Protocol (ARP)-Anfrage als Broadcast in das Ethernet-Netzwerk, in der er wissen möchte, welcher physische Ethernet-Adapter Anfragen für die Adresse 192.168.2.20 beantwortet. Alle Hosts im Netzwerk empfangen diesen ARP-Broadcast, jedoch antwortet nur der Adapter des System i PROD1. In dem ARP-Reply steht nun die richtige MAC-Adresse des PROD1-Ethernet-Adapters.
  4. Der Client empfängt diesen ARP-Reply und erstellt daraufhin einen Eintrag in einer lokalen ARP-Cache-Tabelle. Dieser Eintrag enthält die Zuweisung von IP-Adresse (192.168.2.20) zu MAC-Adresse (00:09:6B:AE:AB:DC). Nun weiß der Client, dass er alle Anfragen für IP-Adresse 192.168.2.20 an den Ethernet-Adapter mit der MAC-Adresse 00:09:6B:AE:AB:DC schicken muss.

Wenn nun Netzwerksitzungen (5250, ODBC, FTP, HTTP, etc.) zur Zieladresse 192.168.2.20 aktiv sind und zum Beispiel das Kabel zum Port 0 des Ethernet-Adapters defekt wird, werden alle aktiven Sitzungen abnormal beendet. Dies ist die Umgebung, wie sie in den meisten System i Installationen zu finden ist. Das bedeutet, dass hier keine Ausfallsicherheit gewährleistet werden kann.

Virtuelle IP-Adressen und ihre Funktionsweise

Wie im vorherigem Abschnitt beschrieben wurde, sind üblicherweise IP-Schnittstellen fest einer physischen Schnittstelle zugeordnet. Fällt eine physische Schnittstelle aus, fällt somit auch der Zugang zu der zugeordneten IP-Schnittstelle/-Adresse aus. Dies verhält sich mit virtuellen IP-Schnittstellen anders. Virtuelle IP-Adressen sind nicht fest einer physischen Schnittstelle zugeordnet, sondern werden dem Betriebssystem zugeordnet. Allgemein wird eine virtuelle IP-Adresse auch als System-IP-Adresse bezeichnet. Da aber eine virtuelle IP-Adresse keiner physischen Schnittstelle (Adapter) zugeordnet ist, antwortet standardmäßig eine physische Schnittstelle auch auf keine ARP-Anfragen für die virtuelle IP-Adresse. Damit eine physische Schnittstelle auch auf ARP-Anfragen einer virtuellen IP-Adresse antwortet, wird ein so genannter Proxy-ARP-Agent eingesetzt. Diese Proxy-ARP-Unterstützung für virtuelle IP-Adressen wurde erstmals mit OS/400 V5R2 zur Verfügung gestellt.

Wird nun eine virtuelle IP-Adresse aktiviert, startet der Proxy-ARP-Agent und wird einer physischen Schnittstelle zugeordnet. Bei mehreren zur Verfügung stehenden physischen Schnittstellen hängt die Zuordnung von der jeweiligen Betriebssystemversion ab.

OS/400 V5R2

Nach der Aktivierung der virtuellen IP-Schnittstelle, startet der Proxy-ARP-Agent auf der physischen Schnittstelle, die zuerst gestartet wurde und die eine fest zugeordnete (physische) IP-Adresse hat, die im selben Subnetz wie die virtuelle IP-Adresse ist. Dabei spielen eventuell unterschiedliche Geschwindigkeiten keine Rolle.

i5/OS V5R3

Bei V5R3 hängt die Zuordnung des Proxy-ARP-Agenten zur physischen Schnittstelle von der Geschwindigkeit der zur Verfügung stehenden physischen Adapterschnittstellen ab. Stehen beispielsweise ein 100MB und ein 1GB Ethernet-Adapter mit jeweils einer fest zugeordneten IP-Adresse aus demselben Subnetz wie die virtuelle IP-Adresse zur Verfügung, wird der Proxy-ARP-Agent der schnelleren physischen Adapterschnittstelle zugeordnet. Dabei spielt die Reihenfolge der Aktivierung keine Rolle.

i5/OS V5R4 oder IBM i V6R1

Ohne besondere Konfigurationsänderungen verhalten sich die beiden Betriebssystemversionen genauso wie V5R3. Jedoch wurde eine neue Option hinzugefügt, welche dem Systemadministrator erlaubt, die Reihenfolge der Proxy-ARP-Agentenzuordnung selbst zu bestimmen.

Sie werden aus den vorherigen Ausführungen bestimmt erkannt haben, dass ich immer von mehreren physischen Adapterschnittstellen geschrieben habe. Dies hat auch seinen guten Grund, denn eine virtuelle IP-Adresse bringt keine Verfügbarkeitsverbesserungen, wenn nur eine physische Netzwerkschnittstelle zur Verfügung steht. Fällt nämlich diese eine physische Schnittstelle aus, sind natürlich auch alle aktiven Sitzungen über diese Schnittstelle unterbrochen. Deshalb benötigen Sie zur Verbesserung der Netzwerkverfügbarkeit mindestens zwei Netzwerkschnittstellen. Die Arbeitsweise von virtuellen IP-Adressen in Verbindung mit mehreren physischen Schnittstellen möchte ich anhand des folgenden Beispiels erklären.

  • IBM System i model 550 mit zwei #5706 2-Port 1GB/100MB/10MB Ethernet-Adaptern
  • IBM i release V5R4 (5722-SS1)
    Das System PROD1 ist über Ethernet im lokalen IP-Netzwerk 192.168.2.0 / 24 über die Adresse 192.168.2.20 zu erreichen, welche als virtuelle IP-Schnittstelle (virtual IP-Address – VIPA) im System konfiguriert ist. Außerdem sind noch drei physische Ethernet-Adapterports konfiguriert.
  • Adapter 1 / Port 0 mit MAC-Adresse 00:09:6B:AE:AB:DC und IP Adresse 192.168.2.11
  • Adapter 1 / Port 1 mit MAC-Adresse 00:09:6B:AE:AB:DD und IP Adresse 192.168.2.12
  • Adapter 2 / Port 0 mit MAC-Adresse 00:09:6B:AE:AB:E1 und IP Adresse 192.168.2.10
  • Der Systemadministrator hat eine bevorzugte Reihenfolge der Schnittstellen konfiguriert, die für die Zuordnung des Proxy-ARP-Agenten für die virtuelle IP-Adresse herangezogen wird.
    1. Wahl ist die Adresse 192.168.2.11
    2. Wahl ist die Adresse 192.168.2.12
    3. Wahl ist die Adresse 192.168.2.10

Im zweiten Beispiel mit einer virtuellen IP-Adresse stellt der Client WORK1 auch eine 5250-Telnet-Verbindung zum System PROD1 her. Die virtuelle IP-Adresse ist dabei die gleiche IP-Adresse wie die der physischen Schnittstelle aus dem ersten Beispiel. D.h., es waren keine Änderungen auf dem DNS-Server notwendig. Es wurde lediglich die bisherige physische IP-Adresse in eine virtuelle IP-Adresse konvertiert. Folgende Schritte laufen dabei im Netzwerk ab: 

Schlagworte: , , , , , , , , , , , , , , , , , , ,

Schreibe einen Kommentar

Sie müssen eingeloggt sein, um einen Kommentar schreiben.