Red Hat Cluster Suite: Konfiguration und Management eines Cluster | ||
---|---|---|
Zurück | Nach vorne |
Ein Red Hat Enterprise Linux LVS-Cluster besteht aus zwei grundlegenden Gruppen: den LVS-Routern und den realen Servern. Um einem einzelnen Punkt des Ausfalls vorzubeugen, sollte jede Gruppe zumindest zwei Systeme enthalten.
Die Gruppe der LVS-Router sollte aus zwei identischen, oder zumindest sehr ähnlich Systemen bestehen, welche Red Hat Enterprise Linux betreiben. Ein System wird als aktiver Router fungieren, während der andere im Hot-Standby Modus bleibt, weswegen diese Systeme so gleiche Kapazitäten wie möglich haben sollten.
Vor dem Auswählen und Konfigurieren der Hardware für die Gruppe der realen Server, müssen Sie sich für eine der drei Typen von LVS Topographien entscheiden.
Die NAT Topographie erlaubt für eine große Bandbreite im Nutzen existierender Hardware, hat allerdings Einschränkungen im Behandeln von großer Arbeitlast, da alle eingehenden und ausgehenden Pakete über den LVS Router gehen.
Die Topographie für einen LVS Cluster, welcher NAT Routing verwendet, ist die am einfachsten zu konfigurierende im Bezug zum Layout des Netzwerks. Dies ist der Fall, da der Cluster lediglich einen Punkt des Zugriffs zum öffentlichen Netzwerk hat. Die realen Server senden alle Antworten durch den LVS Router zurück und befinden sich demnach in ihrem eigenen privaten Netzwerk.
Die NAT Topographie ist die flexibelste im Bezug zur Cluster Hardware, da die realen Server keine Linux Maschinen sein müssen, um fehlerfreien Betrieb im Cluster zu Gewähren. In einem NAT Cluster, benötigt jeder reale Server nur eine NIC, da diese nur dem LVS Router antworten. Jeder LVS Router hingegen, benötigt zwei NICs, um den Netzwerk-Verkehr zwischen den beiden Netzwerken zu regeln. Da diese Topographie einen Flaschenhals (Bottleneck) des Netzwerks im LVS Router mit sich bringt, können Gigabit Ethernet NICs in jedem der LVS Router eingesetzt werden, um die Bandbreite zu erhöhen, die der LVS Router bearbeiten kann. Sind Gigabit Ethernet NICs in den LVS Routern eingesetzt, müssen jegliche Schalter, die die realen Server mit den LVS Routern verbinden, mindestens zwei Gigabit Ethernet Schnittstellen besitzen, um die Last effizient zu handhaben.
Da die NAT-Topographie für einige Konfigurationen die Verwendung von iptables erfordert, kann hier ein erheblicher Aufwand von Software-Konfigurationen, zusätzlich zu Piranha Configuration Tool von Nöten sein. Vor allem FTP-Services und die Benutzung von Firewall-Markierungen erfordern zusätzliche manuelle Konfiguration der LVS-Router, damit diese Anforderungen richtig weiterleiten.
Um einen NAT LVS Cluster einzurichten, muss der Administrator zuerst die Netzwerk-Schnittstellen für das öffentliche und private Netzwerk auf den LVS Routern konfigurieren. In diesem Beispiel, werden die öffentlichen Schnittstellen der LVS Router (eth0) auf dem 192.168.26/24 Netzwerk (ja, ja, ich weiß, dies ist keine weiterleitbare IP, aber lass uns einfach mal annehmen, dass da eine Firewall vor den LVS Routern ist, um die Sache einfacher zu machen) sein, und die privaten Schnittstellen (eth1), welche mit den realen Servern verbunden sind, auf dem 10.11.12/24 Netzwerk.
Auf dem aktiven oder primären LVS Router, könnte das Netzwerk-Skript der öffentlichen Schnittstelle, /etc/sysconfig/network-scripts/ifcfg-eth0, wie folgt aussehen:
DEVICE=eth0 BOOTPROTO=static ONBOOT=yes IPADDR=192.168.26.9 NETMASK=255.255.255.0 GATEWAY=192.168.26.254 |
/etc/sysconfig/network-scripts/ifcfg-eth1 für die private NAT-Schnittstelle auf dem LVS Router könnte folgendermaßen aussehen:
DEVICE=eth1 BOOTPROTO=static ONBOOT=yes IPADDR=10.11.12.9 NETMASK=255.255.255.0 |
In diesem Beispiel, wird die VIP für die öffentliche Schnittstelle des LVS Routers 192.168.26.10 und die VIP für die NAT oder private Schnittstelle 10.11.12.10 sein. Deswegen ist es grundlegend wichtig, dass die realen Server Anforderungen zur VIP der NAT-Schnittstelle zurück senden.
![]() | Wichtig |
---|---|
Das Beispiel für Konfigurationseinstellungen der Ethernet-Schnittstelle in diesem Abschnitt ist für reale IP Adressen auf einem LVS Router, und nicht für die schwebenden IP Adressen. Um die öffentlichen und privaten schwebenden IP Adressen einzustellen, sollte der Administrator Piranha Configuration Tool benutzen, wie in Abschnitt 12.4 und Abschnitt 12.6.1. |
Nach dem Konfigurieren der Netzwerk-Schnittstellen des primären LVS Routers, konfigurieren Sie die realen Netzwerk-Schnittstellen des Backup Routers — unter Beachtung, dass kein Konflikt zwischen IP Adressen auf dem Netzwerk auftritt.
![]() | Wichtig |
---|---|
Stellen Sie sicher, dass jede Schnittstelle auf dem Backup Router das selbe Netzwerk bedient wie die entsprechende Schnittstelle auf dem primären Router. Wenn, zum Beispiel, eth0 auf dem primären Router zum öffentlichen Netzwerk verbindet, muss eth0 auf dem Backup Router auch zum öffentlichen Netzwerk verbinden. |
Der wichtigste Punkt zu beachten bei der Konfiguration der Netzwerk-Schnittstellen der realen Server in einem NAT Cluster ist es den Gateway für die schwebende NAT IP Adresse des LVS Routers zu setzen. In diesem Beispiel, wird die Adresse 10.11.12.10 sein.
![]() | Anmerkung |
---|---|
Sind die Netzwerk-Schnittstellen auf den realen Servern erst einmal oben, werden die Maschinen auf keinem anderen Weg Zugriff zum öffentlichen Netzwerk haben. Dies ist normal. Sie werden allerdings einen Ping zur realen IP der privaten Schnittstelle des LVS Router, in diesem Fall 10.11.12.8, senden können. |
Die Datei /etc/sysconfig/network-scripts/ifcfg-eth0 der realen Server könnte also folgendermaßen aussehen:
DEVICE=eth0 ONBOOT=yes BOOTPROTO=static IPADDR=10.11.12.1 NETMASK=255.255.255.0 GATEWAY=10.11.12.10 |
![]() | Warnung |
---|---|
Wenn ein realer Server mehr als eine Netzwerk-Schnittstelle mit einer GATEWAY= Zeile konfiguriert hat, wird diejenige, die als erste oben ist, den Gateway erhalten. Sind beide, eth0 und eth1 konfiguriert und eth1 ist für LVS Clustering bedacht, können die realen Server deswegen eventuell Anforderungen nicht richtig weiterleiten. Es ist am besten, unnötig zusätzliche Netzwerk-Schnittstellen auszuschalten, indem in deren Netzwerk-Skripten im Verzeichnis /etc/sysconfig/network-scripts/ der Eintrag ONBOOT=no gesetzt wird, oder indem sichergestellt wird, dass der Gateway in der Schnittstelle, welche als erste hochfährt, richtig gesetzt ist. |
In einem einfachen NAT LVS Cluster, in welchem jeder Service nur jeweils einen Port verwendet, wie HTTP auf Port 80, muss der Administrator Paket-Weiterleitung auf den LVS Routern nur einschalten, damit die Anforderungen zwischen dem Außennetz und den realen Servern richtig weitergeleitet werden. Sehen Sie Abschnitt 10.5 für Anleitungen zum Einschalten der Paket-Weiterleitung. Sollten die Services jedoch mehr als einen Port benötigen um die realen Server zu erreichen, sind weitere Konfigurationen von Nöten. Für Informationen zur Erzeugung von Multi-Port Services, welche Firewall-Markierungen benutzen, sehen Sie Abschnitt 11.3.
Ist Weiterleitung auf den LVS-Routern erst einmal eingeschaltet, die realen Server sind eingerichtet, und die Services laufen auf diesen, benutzen Sie Piranha Configuration Tool um den Cluster wie in Kapitel 12 gezeigt zu konfigurieren.
![]() | Warnung |
---|---|
Konfigurieren Sie die schwebende IP für eth0:1 oder eth1:1 nicht durch manuelles Editieren der Netzwerk-Skripte, oder durch Verwendung eines Tools zur Netzwerk-Konfiguration. Anstelle, benutzen Sie Piranha Configuration Tool wie in Abschnitt 12.4 und Abschnitt 12.6.1 gezeigt, um jegliche Cluster-bezogene virtuellen Schnittstellen zu konfigurieren. |
Wenn damit fertig, starten Sie den pulse Service, wie in Abschnitt 12.8 gezeigt. Wenn pulse erst einmal läuft, wird der aktive LVS Router damit beginnen Anforderungen an die Gruppe von realen Servern weiterzuleiten.
Zurück | Zum Anfang | Nach vorne |
Konfigurieren von Services auf den Realen Servern | Nach oben | Zusammenstellen des Clusters |