Dokumentation der Einrichtung eines Lastverteilers mittels LVS-NAT

Transkript

1 Dokumentation der Einrichtung eines Lastverteilers mittels LVS-NAT Philipp Memmel Hardware- und Basiskonfiguration Der Lastverteiler stellt den zentralen Knotenpunkt des gesamten Netzwerkes dar, deswegen sollte an seiner Hardware-Ausstattung nicht gespart werden. Jedoch ist der Lastverteiler im Wesentlichen ein Router, das bedeutet entscheidend sind die CPU und der Arbeitsspeicher und die Netzwerkkarten bzw. deren Bus-Anbindung. In unserem Fall besitzt der Lastverteiler als Prozessor einen AMD Athlon 64 X2 Dual Core Processor mit 2x1024kB Cache bei einer Taktfrequenz von 2600MHz und 2 GB Arbeitsspeicher. Als Netzwerkkarten hat er: Onboard Gigabit, Nvidia-Chipsatz Intel Pro/1000 PT Dual Port, Intel-Chipsatz, Dual-Gigabit-Netzwerkkarte, PCI Express 4x 3 weitere Intel-100MBit-PCI-Netzwerkkarten Zudem benötigt er noch eine Festplatte für das Basissystem, die aber gerne kleinerer Natur sein darf, da er für seine Aufgabe keinen Festplattenplatz benötigt. Das Basissystem stellt in unserem Fall ein Gentoo Linux dar mit einem hardened-kernel der Version Das System bot sich aufgrund seiner hohen Flexibilität in der Konfiguration und Installation der wenigen benötigten Programmen an, in erster Linie aber wegen seiner rudimentären Basiskonfiguration, die keinerlei überflüssige Dienste mit sich bringt, was bedeutet, dass nicht erst eine Stunde damit vergeht, alle Dienste, die man nicht benötigt, zu suchen und abzuschalten. 2 Netzwerkkonfiguration Hat man das Betriebssystem fachgerecht eingerichtet, kann man sich an die Netzwerkkartenkonfiguration machen. Nützlich dazu ist ein kleines Programm namens ethtool 1, mit dem man schnell sehen kann, welche Netzwerkkarte man jetzt soeben mit dem entsprechenden Switch verbunden hat und wie sie heißt. Hat man das erfolgreich geklärt, empfiehlt es sich, in dem File /etc/udev/rules.d/70-persistent-net.rules die Namen der Netzwerkinterfaces etwas sinnvoller zu benennen als eth*, zum Beispiel 1ernetz oder servernetz. Folgende Netzwerke sind vorhanden bzw. werden erstellt, an die der Lastverteiler wie folgt angebunden ist: 1 Teil des Projekts gkernel: mit Gentoo zu installieren: emerge ethtool

2 /24, IP: , Netzwerkinterface servernetz, Onboard-Gigabit-Karte, Anbindung durch Gigabit-Switch an die Server, die, hinter dem Lastverteiler versteckt, die Dienste bereit stellen /24, IP: , Netzwerkinterface gateway, eine der 100MBit-Karten, Uplink zum Gateway ( ) /24, IP: , Netzwerkinterface 1ernetz, 1. Port der Dual-Port-Gigabit- Karte, Anbindung des Subnetzes des Computerraums /24, IP: , Netzwerkinterface 2ernetz, 2. Port der Dual-Port-Gigabit- Karte, Anbindung des Subnetzes des Computerraums /24, IP: , Netzwerkinterface 3ernetz, eine der 100MBit-Karten, Anbindung des Subnetzes der Hausvernetzung /24, IP: , Netzwerkinterface 5ernetz, eine der 100MBit-Karten, Anbindung des Subnetzes der Mensa 4 Defaultroute: (Internet-Uplink) Um den Überblick zu wahren ist am Ende dieser Dokumentation die Netzkonfiguration grob aufgeschlüsselt in einem Diagramm (6) dargestellt. 3 Die Theorie LVS steht für Linux Virtual Server 5 und bedeutet, dass das System, auf dem es läuft virtuelle Dienste zur Verfügung stellt, die in Wirklichkeit von anderen Servern hinter dem Lastverteiler- System bereitgestellt werden. Wir haben uns hier für das Prinzip des LVS-NAT entschieden, das bedeutet, dass der Lastverteiler die Rolle eines Routers hat, der NAT (Network Address Translation) betreibt. Für die Clients erscheint der Lastverteiler bei diesem Prinzip als alleiniger Server, der wie ein realer Server die Dienste bereitstellt. Um diesen Schein zu wahren, muss der Lastverteiler sicherstellen, dass sich keine Pakete aus dem Servernetz in die Client-Netze verirren. Dies realisiert man mit Hilfe von Source-NAT (auch SNAT ), also herkunftsorientiertem NAT, was bedeutet, dass alle Pakete, die aus dem Servernetz den Lastverteiler erreichen (also Antwort-Pakete auf Dienst-Anfragen der Clients an den Lastverteiler, die dieser weitergeroutet hat), eine neue Absenderadresse erhalten, nämlich die des an das Client-Netz angebundene Netzwerkinterface des Lastverteilers. Somit können die Clients nicht zwischen echten und virtuellem Server(n) unterscheiden. Eine spezielle und wohl die bekannteste Form des SNAT ist das Masquerading, mit dem wir unseren Lastverteiler im Folgenden realisieren. Der Lastverteiler besitzt zahlreiche verschiedene Scheduler, das heißt Algorithmen, die ihm angeben, zu welchem der verschiedenen angegeben Realservern er die ankommende Verbindung aufbaut, um die Last gleichmässig zu verteilen. Mit diesen kann man beliebig experimentieren, wir haben in unserem Beispiel den sed-scheduler verwendet (sed steht für Shortest Expected Delay). Weit verbreitet ist auch der wlc-scheduler. 2 aufgrund von fremder Hardware in der Mensa-Küche mussten wir die IP des Gateways auf die eigentlich dem Lastverteiler zugehörige IP ändern, dementsprechend endet die IP des Lastverteilers in diesem Netz auf die 203. Da hierüber nur Internettraffic fließt, sind 100MBit mehr als ausreichend 3 Da der Switch des Netzes /24 nur 100MBit-Anschlüsse besitzt, machte es auch hier nicht viel Sinn, eine Gigabit-Karte zu verwenden 4 Aufgrund eines fehlenden weiteren Gigabit-Anschlusses auf dem Switch, an dem die Mensa hängt, genügt auch hier eine 100MBit-Karte 5

3 4 Einrichtung/Konfiguration des Lastverteilers Ist die Theorie nun geklärt, kann man sich auch schon an die Einrichtung seines Systems machen. 4.1 Die Kernel-Konfiguration Da IPTables und auch LVS Teile des Kernels sind, müssen einige Optionen einkompiliert bzw. als Module kompiliert und geladen werden, um Masquerading und LVS nutzen zu können. Hier ein Listing der Kernel-Optionen: Networking ---> [*] Networking support Networking options ---> [*] Network packet filtering framework (Netfilter) ---> Core Netfilter Configuration ---> [*] Netfilter connection tracking support IP: Netfilter Configuration ---> [*] IPv4 connection tracking support (required for NAT) [*] IP tables support (required for filtering/masq/nat) [*] Full NAT [*] MASQUERADE target support [*] TCP/IP networking IP: Virtual Server Configuration ---> [*] IP virtual server support (EXPERIMENTAL) [*] TCP load balancing support [*] weighted least-connection scheduling [*] shortest expected delay scheduling 4.2 Benötigte Software Für den Betrieb des Lastverteiler werden im Prinzip neben dem Basissystem lediglich zwei kleine Programme benötigt, iptables und ipvsadm. Um später einige nicht unwichtige Features zur Verfügung zu haben, ist es jedoch ratsam, den Lastverteiler mit dem Dämon ldirectord zu betreiben, der Teil des Pakets heartbeat ist. Unter Gentoo ist die Installation mit einem USE="ldirectord" emerge iptables ipvsadm heartbeat bereits erledigt und man kann zum nächsten Punkt schreiten. 4.3 IPTables-Konfiguration Die IPTables stellen das Masquerading zur Verfügung, zuvor muss aber erst noch das Routing aktiviert werden. Das erreicht man mit $ echo 1 > /proc/sys/net/ipv4/ip_forward für das laufende System und durch $ echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf um die Einstellung beim Reboot zu erhalten. Nun kann man sich an die Erstellung der IPTables-Regeln machen, die man am Besten in einem Skript wie diesem zusammenfasst, die Kommentare sollten selbsterklärend sein.

4 #!/bin/bash # Definition der Variablen der Netzwerkinterfaces und der Subnetze, # sodass man diese schnell ausbessern kann, ebenso der Pfad des # iptables-binary ETH1="1ernetz" ETH2="2ernetz" ETH3="3ernetz" ETH4="4ernetz" N1=" /24" N2=" /24" N3=" /24" N4=" /24" N10=" /24" IPTABLES="/sbin/iptables" # Grundlegende Definitionen der Regeln: # Flushe zuerst die Tabellen, auch die nat-tabelle $IPTABLES -F $IPTABLES -F -t nat # Grundlegende Policy: grundsaetzlich soll alles erlaubt sein $IPTABLES -P FORWARD ACCEPT $IPTABLES -P INPUT ACCEPT $IPTABLES -P OUTPUT ACCEPT # Definition des Masquerading, jeweils fuer alle Subnetze $IPTABLES -t nat -A POSTROUTING -o $ETH1 -s $N10 -j MASQUERADE $IPTABLES -t nat -A POSTROUTING -o $ETH2 -s $N10 -j MASQUERADE $IPTABLES -t nat -A POSTROUTING -o $ETH3 -s $N10 -j MASQUERADE $IPTABLES -t nat -A POSTROUTING -o $ETH4 -s $N10 -j MASQUERADE # Verhindern, dass sonstiger Verkehr ueber den Lastverteiler laeuft $IPTABLES -A FORWARD -s $N1 -d $N10 -j DROP $IPTABLES -A FORWARD -s $N2 -d $N10 -j DROP $IPTABLES -A FORWARD -s $N3 -d $N10 -j DROP $IPTABLES -A FORWARD -d $N10 -s $N1 -j DROP $IPTABLES -A FORWARD -d $N10 -s $N2 -j DROP $IPTABLES -A FORWARD -d $N10 -s $N3 -j DROP # Speichere die Regeln, dass sie bei einem Neustart automatisch geladen werden /etc/init.d/iptables save Dieses Skript muss nun ausgeführt werden, um die Regeln zu laden. Sollten Fehler auftreten, sind höchstwahrscheinlich nicht alle nötigen Module kompiliert und/oder geladen bzw. nicht in den Kernel einkompiliert. 4.4 LVS-Konfiguration Die Konfiguration des LVS übernimmt der Dämon ldirectord. Sein Config-File heißt /etc/ha.d/conf/ldirectord.cf. Sein Hauptnutzen ist der, dass er - im Gegensatz zur direkten Konfiguration des LVS über das Programm ipvsadm - den Zustand der Realserver überwacht und dynamisch nicht funktionierende Realserver automatisch aus der Kernel-Tabelle entfernt und, sobald sie wieder laufen, wieder hinzufügt. Hier ein Beispiel-Config-File: logfile="/var/log/ldirectord.log"

5 # Liest das Config-File neu ein, sobald es veraendert wurde: autoreload=yes # Beispiel fuer unverschluesseltes LDAP virtual = :389 service = ldap real = :389 masq 1 real = :389 masq 1 scheduler = sed protocol = tcp # Beispiel fuer Apache/HTTP (hierzu muss im Basisverzeichnis # des Apache-Servers eine Datei namens test.html mit dem Inhalt # "OK" vorhanden sein: virtual = :80 real = :80 masq 1 real = :80 masq 1 service = http scheduler = sed protocol = tcp request = "/test.html" receive = "OK" Die meisten anderen Dienste sind genauso zu konfigurieren, jeder einzelne Dienst muss jedoch noch für jedes andere Interface angegeben werden, auf dem er angeboten werden solll. Nach dem Starten des ldirectord zum Beispiel bei Gentoo über das Startskript /etc/init.d/ldirectord start sollte der Lastverteiler bereits funktionieren. Mit einem Blick in das Logfile /var/log/ldirectord.log lässt es sich überprüfen, die Kernel-Tabelle kann man sich auch mit dem Aufruf ipvsadm anzeigen lassen. 5 Tips und Tricks für aufständische Dienste 5.1 FTP Für FTP-Zugriff muss man die Ports 20 und 21 auf die Realserver weiterleiten, allerdings ergeben sich hierdurch einige Probleme, die aber durch das Modul ip vs ftp gelöst werden. Das bloße Laden des Moduls ermöglicht ganz normalen FTP-Zugriff. Die Gründe möchte ich hier nicht weiter ausführen. Das Modul ist hier zu finden: Networking ---> [*] Networking support Networking options ---> IP: Virtual Server Configuration ---> <M> FTP protocol helper 5.2 NFS Da NFS über den Portmapper Ports auszuhandeln versucht, der Lastverteiler aber nicht wüsste, welche das wären, muss man den NFS-Diensten auf den Realservern feste Ports zuweisen (unter Gentoo siehe /etc/conf.d/nfs und /etc/sysctl.conf). Sind diese Ports zugewiesen, kann man

6 sie dem ipvsadm übergeben und auch NFS ist kein Problem mehr. Der Portmapper lauscht normalerweise auf TCP-Port 111, der im ipvsadm angegeben werden muss. Als UDP-basiertes Protokoll laufen über Port 111 aber scheinbar noch UDP-Verbindungen, für die ein weiterer Eintrag angelegt werden muss. Für den nfsd muss der UDP-Port 2049 angegeben werden, je nach Festsetzung der Ports für die anderen NFS-Dienste (statd, lockd etc.) müssen diese ebenfalls den jeweiligen UDP-Port auf den virtuellen Interfaces des Lastverteilers erhalten. Da NFS inzwischen auch über TCP betrieben werden kann, macht es allerdings Sinn, die UDP- Ports von nfsd, statd, lockd etc. auch auf TCP-Basis zugänglich zu machen. 5.3 Xdmcp Xdmcp läuft gewöhnlich auf dem UDP-Port 177, allerdings wird dieser nur zum Aushandeln von Basisinformationen benutzt, für die eigentliche X11-Umleitung wird ein Port ab 6000 gewählt. Jedoch benötigt X11 eine direkte Verbindung zu den Clients, so schien es die einfachste Möglichkeit die iptables-regeln etwas zu lockern, um den direkten Zugriff zu erlauben. Vor den Regeln, die den restlichen Verkehr über die Interfaces verhindern, ist deshalb einzufügen: $IPTABLES -A FORWARD -s d /24 -p tcp \ -m tcp --dport 6000:6005 -j ACCEPT $IPTABLES -A FORWARD -s /24 -d p tcp -m tcp \ --sport 6000:6005 -j ACCEPT ist hierbei die IP eines Realservers, der die X11-Anmeldung zur Verfügung stellt. Bei mehreren Realservern sind die Regeln auch für die IPs der anderen Realserver einzutragen. 5.4 Probleme mit der Überwachung der Realserver Der Dämon ldirectord unterstützt verschiedene Service-Modi, also verschiedene Möglichkeiten der Überwachung der Realserver. Der Default-Wert für die Option checktype ist negotiate. Das bedeutet, dass ldirectord den entsprechenden Service nachfragt und bei einer entsprechenden Antwort des Dienstes den Realserver als alive deklariert. Mit der zusätzlichen Option service kann man für verschiedene Dienste (z.b. http, ftp, ldap,...; nachzulesen in der Manpage von ldirectord) diese Abfrage einstellen. Es gibt allerdings Dienste, mit denen ldirectord nicht kommunizieren kann, hier ist man gezwungen auf eine andere, weniger genauere Methode auszuweichen, zum Beispiel indem man checktype auf den Wert connect setzt. Bei diesem Wert baut ldirectord lediglich eine TCP/IP-Verbindung zum Realserver auf, bei deren Erfolg der Realserver als alive deklariert wird. Für UDP-Dienste wie etwa NFS (DNS fällt nicht darunter, hierfür gibt es eine spezielle service-definition) muss man sich mit noch weniger begnügen: mit checktype = ping testet ldirectord lediglich, ob der Realserver auf ein ICMP-Anfrage eine Antwort sendet und setzt dessen Status bei Erfolg auf alive. Alternativ dazu existieren noch die Werte on und off für checktype, mit denen entweder der Eintrag des Realservers unabhängig von seinem tatsächlichen Zustand in die Kerneltabelle eingefügt (on) oder aus ihr entfernt (off ) wird. Näheres ist der Manpage zu entnehmen.

7 6 Anhang Abbildung 1: Grobe Struktur des Netzes am Augustinus-Gymnasium Weiden