High Availibility Cluster Dokumentation

Transkript

1 High Availibility Cluster Dokumentation Michael Thessel December 28,

2 Contents 1 Einleitung 3 2 Komponenten VServer Linux High Availability (Linux HA) Distributed Remote Block Device (DRBD) Konzept 4 4 Implementierung Verwendete Software und Versionen Grobkonzept Installation Debian Basis System Installation DRBD Kernel Patch Installation DRBD User Space Tools DRBD Devices vorbereiten DRBD Device Nodes erstellen Verzeichnisse /etc/fstab Installation VServer Kernel Patch Installation VServer-Utils Installation Heartbeat Spiegeln auf die zweite Node Konfiguration DRBD /etc/drbd.conf Konfiguration VServer Installation eines VServers /etc/init.d/vservers Konfiguration Heartbeat /etc/ha.d/ha.cf /etc/ha.d/authkeys /etc/ha.d/haresources /etc/ha.d/resource.d/cluster Syncronisation der Konfiguration Vorteile Ausfallicherheit Aktiv-Aktiv Custer Filesystemredundanz Nachteile Versionsabhängigkeit Zusätzliche Host Betriebssysteme Kernel System Netzwerk Spiegelung

3 1 Einleitung Um den Wartungsaufwand und somit auch die Dienstequalität zu verbessern wurde vom EDV-Team eine Zentralisierung verschiedener Dienste angestrebt. Dadurch verschwindet allerdings auch die vorher teilweise vorhandene Redundanz einiger Dienste. Dies führt zu verstärkten Problemen beim Ausfall eines Dienstes. Hoch frequentierte Dienste sollten deshalb ausfallsicher ausgelegt werden. Folgende Dienste sind als Beispiele zu nennen: 1. Mail Services (SMTP, IMAP, POP) 2. Druck Services (CUPS) 3. DHCP, DNS,... Mit diesem Projekt soll eine Clusterlösung untersucht werden, welche verschiedene Dienste im Institut hochverfügbar bereitstellen soll. 2 Komponenten Die hier untersuchte Lösung ist eine reine Softwarelösung und besteht aus folgenden Komponenten: 1. VServer ( 2. Linux HA ( 3. DRBD ( In den folgenden Abschnitten sollen die Komponenten vorgestellt und deren Zusammenspiel erläutert werden. 2.1 VServer Diese Komponente ist das Kernstück des Konzeptes. Es handelt sich hierbei um einen Linux Kernel Patch, der es ermöglicht, mehrere Linux Instanzen auf einem Host System laufen zu lassen. Die Instanzen werden in einer abggegrenzten so genannten Jail (Gefängnis) Umgebung gestartet, die die einzelnen Linux Instanzen vollständig voneinander abgrenzt. In Kombination mit einem verteilten Netzwerk Dateisystem (siehe Abschnitt 2.3) entsteht die Möglichkeit zwei identische Linux-Systeme (Master, Slave) auf zwei verschiedenen Rechnern zur Verfügung zu stellen. Im Falle eines Systemausfalls des Master-Systems könnte auf das zweite redundante Slave-System gewechselt werden, welches den aktuellen Stand des Master-Systems darstellt. 2.2 Linux High Availability (Linux HA) Die vom Linux HA Projekt entwickelte Software Heartbeat ermöglicht die Überwachung der Nodes und das Umschalten auf die Slave Node im Fehlerfall. Hierbei kann das Host System an sich überwacht werden, als auch die Dienste der jeweiligen Linux-VServer Instanzen. 3

4 Figure 1: Schema Distributed Remote Block Device 2.3 Distributed Remote Block Device (DRBD) Durch DRBD wird es möglich die Dateisysteme der Linux-VServer Instanzen auf der Slave Node über das Netzwerk zu spiegeln (Siehe Abbildung 1). Dadurch ist immer eine aktuelle Kopie des Linux Dateisystems auf der Slave Node vorhanden. Im Falle eines Systemausfalls der Master Node kann die Slave Node sofort mit den aktuellen Daten die Master Node ersetzen. 3 Konzept Das angestrebte Ziel dieses Projektes ist es, ein 2 Node aktiv-aktiv Cluster (siehe Grafik 1) aufzusetzen, welches mindestens 2 Dienste ausfallsicher bereitstellt. Dazu werden zwei Debian Linux Basis-Systeme aufgesetzt, welche den VServer und den DRBD Kernel-Patch eingespielt bekommen. Zusätzlich wird auf beiden Nodes das Linux HA Paket installiert, welches das Cluster überwachen und im Fehlerfall zwischen den Nodes umschalten soll. 4

5 4 Implementierung 4.1 Verwendete Software und Versionen 1. Debian Etch 2. Kernel (vanilla) 3. drbd VServer 2.0 (patch vs2.0.diff) 5. util-vserver patch fix02.diff (Util VServer Patch) 7. heartbeat (1.2.3.cvs ) (Debian Paket) 4.2 Grobkonzept 1. Debian Basissystem installieren 2. Konfiguration Netzwerk/Hostname/ Einspielen der Kernel Patches 4. Kernel kompillieren und installieren 5. Spiegeln dieses Systems (bolek) auf einen 2. Rechner (lolek) 6. Konfiguration des 2. Rechners (Netzwerk/Hostname/...) 7. Konfiguration DRBD 8. Konfiguration VServer 9. Konfiguration Heartbeat 10. Testen der Installation 4.3 Installation Debian Basis System Bei der Installation des Basissystems ist darauf zu achten, möglichst keine unnötigen Dienste laufen zu lassen. Im hier dargestellten Beispiel läuft auf den Hostsystemen ausschließlich ein SSH Server. Dadurch werden Konflikte mit den Linux Instanzen vermieden. Ausserdem sollte bei der Partitionierung der Festplatte genügend Platz für die VServer Partitonen gelassen werden. Für eine Aktiv-Aktiv Konfiguration (Siehe Abschnitt 5.2) werden mindestens 2 zusätzliche Partitionen benötigt. 5

6 4.4 Installation DRBD Kernel Patch Kernel Sources installieren: bolek :# cd / usr / src bolek :# wget http :// www. kernel. org / pub / linux / kernel /v2.6/\ linux tar. bz2 bolek :# tar - xjvf linux tar. bz2 bolek :# ln - s linux linux Kernel patchen: bolek :# cd / usr / src bolek :# wget http :// oss. linbit. com / drbd /0.7/ drbd tar.gz bolek :# tar - xzvf drbd tar. gz bolek :# cd / usr / src / linux bolek :# patch -p1 <../ drbd / patch - linux -drbd In der /usr/src/linux/.config folgenden Schalter setzen: CONFIG_BLK_DEV_DRBD =y Als nächstes den Kernel kompilieren (Dieser Schritt kann an dieser Stelle ausgelassen werden da der Kernel im Abschnitt 4.7 nocheinmal kompiliert wird. Zur Sicherheit wird allerdings angeraten den Kernel zweimal zu kompillieren, um eventuelle Fehler auszuschliessen): bolek :# make clean bzimage modules modules_install Zum Abschluß den Kernel abhängig vom verwendeten Bootloader installieren. 4.5 Installation DRBD User Space Tools bolek :# cd / usr / src /drbd bolek :#./ configure bolek :# make tools bolek :# make install 4.6 DRBD Devices vorbereiten DRBD Device Nodes erstellen Für ein aktiv-aktiv Cluster werden 2 Partitionen benötigt (Siehe Abschnitt 5.2). Um diese als DRBD Devices nutzen zu können müssen 2 DRBD Device Nodes erstellt werden: bolek :# mknod / dev / drbd1 b bolek :# mknod / dev / drbd2 b Verzeichnisse Die Mount Points für die DRBD Devices anlegen: bolek :# mkdir - p / vservers / group1 bolek :# mkdir - p / vservers / group2 6

7 4.6.3 /etc/fstab Die Mount Points für die DRBD Devices eintragen: / dev / drbd0 / vservers / group1 ext3 defaults, errors = remount -ro 0 1 / dev / drbd1 / vservers / group2 ext3 defaults, errors = remount -ro Installation VServer Kernel Patch Im nächsten Schritt wird der Kernel mit dem VServer Patch gepatcht und neu kompiliert. bolek :# cd / usr / src / bolek :# wget http :// thfloor.at/ vserver / s_rel26 /v2.0/\ patch vs2.0. diff bolek :# cd linux bolek :# patch -p1 <../ patch vs2.0. diff In der /usr/src/linux/.config folgende Schalter setzen: CONFIG_VSERVER = y CONFIG_VSERVER_LEGACYNET =y # Linux VServer CONFIG_VSERVER_LEGACY =y CONFIG_VSERVER_PROC_SECURE =y CONFIG_INOXID_UGID24 =y Als nächstes den Kernel kompilieren und abhängig vom installierten Bootloader installieren: bolek :# make clean bzimage modules modules_install 4.8 Installation VServer-Utils Zum Management der VServer werden die VServer-Utils benötigt, diese sind auf der VServer Website erhältlich. bolek :# cd / usr / src bolek :# wget http :// thfloor.at/ vserver / s_rel26 /v2.0/\ util - vserver tar. bz2 bolek :# tar - xjvf util - vserver tar. bz2 bolek :# cd util - vserver bolek :#./ configure bolek :# make bolek :# make install Den VServern Zugriff auf das /proc Dateisystem geben: bolek :# ln -s / usr / local / etc / init.d/ vprocunhide \ / etc / init.d/ vprocunhide bolek :# ln -s / etc / init.d/ vprocunhide / etc / rc2.d/ S99vprocunhide bolek :# ln -s / etc / init.d/ vprocunhide / etc / rc3.d/ S99vprocunhide Das VServer etc-verzeichnis nach /etc verlinken: ln -s / usr / local / etc / vservers / etc 7

8 4.9 Installation Heartbeat bolek :# apt - get install heartbeat 4.10 Spiegeln auf die zweite Node Da die Basisinstallation auf beiden Nodes die selbe ist, können im nächsten Schritt die Daten auf die zweite Node gespiegelt werden. Sollte dies nicht möglich sein, können alternativ auf der zweiten Node alle vorangegangenen Installationsschritte wiederholt werden. Im hier vorgestellten Projekt wurde zur Spiegelung das Tool Partimage verwendet Konfiguration DRBD /etc/drbd.conf Diese Datei muß auf beiden Nodes identisch vorhanden sein. resource group1 { protocol C; incon -degr - cmd " echo! DRBD! pri on incon -degr wall ; \ sleep 60 ; halt - f"; startup { wfc - timeout 0; degr - wfc - timeout 120; } disk { on -io - error detach ; } } syncer { group 0; rate 10M; } on lolek { device / dev / drbd0 ; disk / dev / hda2 ; address :7 788; meta - disk internal ; } on bolek { device / dev / drbd0 ; disk / dev / hda2 ; address :7 788; meta - disk internal ; } resource group2 { protocol C; incon -degr - cmd " echo! DRBD! pri on incon -degr wall ; \ sleep 60 ; halt - f"; startup { wfc - timeout 0; degr - wfc - timeout 120; } disk { on -io - error detach ; } syncer { group 0; rate 10M; } 8

9 } on lolek { device / dev / drbd1 ; disk / dev / hda3 ; address :7 789; meta - disk internal ; } on bolek { device / dev / drbd1 ; disk / dev / hda3 ; address :7 789; meta - disk internal ; } Anchließend müssen noch auf beiden Nodes die DRBD Devices aktiviert werden: bolek :# drbdadm -- --do -what -I-say up all bolek :# drbdadm primary group1 bolek :# drbdadm secondary group2 lolek :# drbdadm -- --do -what -I-say up all lolek :# drbdadm primary group2 lolek :# drbdadm secondary group1 Nach der Syncronisation sollten die DRBD Devices beide consitent sein: bolek :# cat / proc / drbd version : ( api :77/ proto :74) SVN Revision : 1989 build by root@ node2, : 02: 50 0: cs: Connected st: Primary / Secondary ld: Consistent ns : nr :0 dw :0 dr : al :0 bm :98 lo :0 pe :0 ua :0 ap :0 1: cs: Connected st: Secondary / Primary ld: Consistent ns :0 nr : dw : dr :0 al :0 bm :589 lo :0 pe :0 ua :0 ap :0 2: cs: Unconfigured 3: cs: Unconfigured 4: cs: Unconfigured 5: cs: Unconfigured 6: cs: Unconfigured 7: cs: Unconfigured Nun sollte das DRBD-Netzwerkdateisystem lauffähig sein. überprüft werden: lolek :# umount / vservers / group * lolek :# drbdadm secondary all bolek :# drbdadm primary all bolek :# mount / vservers / group1 bolek :# mount / vservers / group2 bolek :# touch / vservers / group1 / testfile bolek :# touch / vservers / group2 / testfile bolek :# umount / vservers / group1 bolek :# umount / vservers / group2 bolek :# drbdadm secondary all Dies kann folgendermaßen 9

10 lolek :# drbdadm primary all lolek :# mount / vservers / group1 lolek :# mount / vservers / group2 lolek :# ls / vservers / group * Wenn nun die zwei testfile Dateien angezeigt werden funktioniert die Spiegelung Konfiguration VServer Installation eines VServers Nachdem das Dateisystem aufgesetzt ist kann nun die Basisinstallation der VServer- Instanzen beginnen. Diese wird der Einfachheit halber auf einer Node ausgeführt. Im ersten Schritt weden die VServer Rootverzeichnisse gemountet: lolek :# umount / vservers / group * lolek :# drbdadm secondary all bolek :# drbdadm primary all bolek :# mount / vservers / group1 bolek :# mount / vservers / group2 Zur Basisinstallation der VServer-Instanzen wird folgendes Script verwendet, wobei jeweils der Hostname, die Netzwerkkonfiguration, das Rootverzeichnis und der Context angepasst werden müssen. Für die hier gewählte aktiv-aktiv Konfiguration müßen zwei VServer installiert werden: #!/ usr / bin / tcsh set NAME = vserver1 set IP = /24 set NETINTERFACE = eth0 set ROOTDIR = / vservers / group1 set CONTEXT = 100 vserver - v $NAME build \ -- force \ -- rootdir $ROOTDIR \ - m debootstrap \ -- hostname $NAME \ -- netdev $NETINTERFACE \ -- interface $IP \ -- context $CONTEXT -- \ -d sarge \ -m http :// ftp.at. debian. org / debian / Anstatt zwei VServer zu installieren, kann auch nur ein VServer installiert werden und anschließend mit vserver-copy die zweite Instanz durch eine Kopie der ersten erzeugt werden. Nachdem beide VServer installiert sind sollten nun noch die Startscripte bereinigt werden: bolek :# cd / vservers / group1 / vserver1 / etc / rc0.d bolek :# rm K20makedev K25hwclock. sh S30urandom S31umountnfs. sh \ S35networking S36ifupdown S40umountfs S90halt K89klogd bolek :# cd / vservers / group2 / vserver2 / etc / rc0.d bolek :# rm K20makedev K25hwclock. sh S30urandom S31umountnfs. sh \ 10

11 S35networking S36ifupdown S40umountfs S90halt K89klogd bolek :# cd / vservers / group1 / vserver1 / etc / rc6.d bolek :# rm K20makedev K25hwclock. sh S30urandom S31umountnfs. sh \ S35networking S36ifupdown S40umountfs S90reboot K89klogd bolek :# cd / vservers / group2 / vserver2 / etc / rc6.d bolek :# rm K20makedev K25hwclock. sh S30urandom S31umountnfs. sh \ S35networking S36ifupdown S40umountfs S90reboot K89klogd bolek :# cd / vservers / group1 / vserver1 / etc / rcs.d bolek :# rm S05keymap. sh S48console - screen. sh S50hwclock. sh \ S40networking S45mountnfs. sh S10checkroot. sh \ S02mountvirtfs S30procps. sh S35mountall. sh \ S36mountvirtfs S39ifupdown S30checkfs. sh \ S18ifupdown - clean S18hwclockfirst. sh bolek :# cd / vservers / group2 / vserver2 / etc / rcs.d bolek :# rm S05keymap. sh S48console - screen. sh S50hwclock. sh \ S40networking S45mountnfs. sh S10checkroot. sh \ S02mountvirtfs S30procps. sh S35mountall. sh \ S36mountvirtfs S39ifupdown S30checkfs. sh \ S18ifupdown - clean S18hwclockfirst. sh bolek :# cd / vservers / group1 / vserver1 / etc / rc2.d bolek :# rm S20makedev S11klogd bolek :# cd / vservers / group2 / vserver2 / etc / rc2.d bolek :# rm S20makedev S11klogd Die VServer können nun gestartet werden: bolek :# vserver vserver1 start bolek :# vserver vserver2 start Und der VServer Context kann mit: bolek :# vserver vserver1 enter betreten werden /etc/init.d/vservers Damit die VServer automatisch beim Start des Host Systems gestartet werden, werden für die VServer Startscripte erstellt: Startscript für vserver1: #!/ bin / bash VSERVERNAME =" vserver1 " DRBDGROUP =" group1 " SHARED_MOUNTPOINT ="/ vservers / group1 " VSERVERNETINTERFACE =" eth0 " VSERVERIP =" " DRBD ="/ etc / init.d/ drbd " DRBDADM ="/ sbin / drbdadm " MOUNT ="/ bin / mount " UMOUNT ="/ bin / umount " VSERVER ="/ usr / local / sbin / vserver " 11

12 SENDARP ="/ usr / lib / heartbeat / send_arp " VSERVERMAC = ifconfig $ V S E R V E R N E T I N T E R F A C E grep HWaddr \ awk { print ( $5 )} NETMASK = ifconfig $VSERVERNETINTERFACE grep Mask \ awk { print ( $4 )} cut -d: -f2 VSERVERBROADCAST = ifconfig $VSERVERNETINTERFACE \ grep Bcast awk { print ( $3 )} cut -d: -f2 case "$1" in start ) echo - n " Starting $VSERVERNAME :" $DRBDADM primary $DRBDGROUP $MOUNT $SHARED_MOUNTPOINT ;; stop ) ;; *) ;; esac exit 0 $VSERVER $VSERVERNAME start $SENDARP $VSERVERNETINTERFACE $VSERVERIP $VSERVERMAC \ $VSE RVERB ROADCA ST $NETMASK echo - n " Stopping $VSERVERNAME :" $VSERVER $VSERVERNAME stop $UMOUNT $S HA RE D_M OU NT PO IN T $DRBDADM secondary $DRBDGROUP echo " Usage : $0 { start stop }" exit Konfiguration Heartbeat /etc/ha.d/ha.cf In dieser Datei werden die Grundeinstellungen von Heartbeat vorgenommen. beiden Nodes debugfile / var / log /ha - debug logfile / var / log /ha - log logfacility local0 keepalive 1 deadtime 15 warntime 5 initdead 120 udpport 694 bcast eth1 auto_failback on node lolek node bolek respawn hacluster / usr / lib / heartbeat / ipfail Um die 12

13 debug /etc/ha.d/authkeys auth 1 1 crc /etc/ha.d/haresources bolek lolek vserver1 vserver /etc/ha.d/resource.d/cluster #!/ bin / bash SHARED_MOUNTPOINT ="/ vservers " DRBD ="/ etc / init.d/ drbd " DRBDADM ="/ sbin / drbdadm " MOUNT ="/ bin / mount " UMOUNT ="/ bin / umount " VSERVER ="/ etc / init.d/ vservers " case "$1" in start ) echo - n " Starting cluster :" $DRBDADM primary all $MOUNT $SHARED_MOUNTPOINT $VSERVER start ;; stop ) ;; *) ;; esac exit 0 echo "." echo - n " Stopping cluster :" $VSERVER stop sleep 2 $UMOUNT $S HA RE D_M OU NT PO IN T $DRBDADM secondary all $DRBDADM wait_connect all echo "." echo " Usage : $0 { start stop }" exit Syncronisation der Konfiguration Da auf beiden Nodes die Konfigurationsdateien für die VServer sowie für Heartbeat und DRBD identisch vorhanden sein müssen wird mittels rsync die Konfiguration auf den beiden Nodes syncron gehalten. Dazu wurde festgelegt, dass Konfigurationsänderungen 13

14 Figure 2: Schema Aktiv-Aktiv Cluster ausschließlich auf node1 (Bolek) ausgeführt werden und anschließend ein Syncronisationsscript aufgerufen wird. sync config rsync -az --rsh = ssh / etc / vservers / lolek :/ etc / vservers rsync -az --rsh = ssh / etc / drbd. conf lolek :/ etc / drbd. conf rsync -az --rsh = ssh / etc /ha.d/ lolek :/ etc /ha.d rsync -az --rsh = ssh / etc / init.d/ vserver1 \ lolek :/ etc / init.d/ vserver1 rsync -az --rsh = ssh / etc / init.d/ vserver2 \ lolek :/ etc / init.d/ vserver2 5 Vorteile 5.1 Ausfallicherheit Das Hauptziel dieses Projektes ist es Dienste möglichst ausfallischer auszulegen. Im hier vorgestellten Projekt wurde die Ausfallsicherheit der Dienste wesentlich verbessert, da jetzt der Totalausfall einer Node in kürzester Zeit abgefangen werden kann. 5.2 Aktiv-Aktiv Custer Die verwendete Komponentenzusammenstellung ermöglicht die Konfiguration von aktivaktiv Clustern (Siehe Grafik 2). Das bedetet, dass auf beiden verwendeten Nodes verschiedene Dienste laufen und im Falle eines Ausfalls eine von beiden Nodes die Dienste der anderen Node mit übernimmt. Hierbei sollte allerdings beachtet werden, dass im Falle eines Systemausfalls die aktive Node eventuell eine stark erhöhte Last bewältigen muß. Dies sollte bei der Dimensionierung der Nodes berücksichtigt werden. 5.3 Filesystemredundanz Durch das beschriebene redundante Netzwerkfilesystem sind alle Dateisysteme der installierten Linux Instanzen doppelt auf verschiedenen Festplatten vorhanden. Dadurch ist im Falle eines Festplattenausfalls auf einem der beiden Nodes aktuelle Kopie des Dateisystems vorhanden. Dadurch wird die Datenrettung und -wiederherstellung wesentlich schneller, sicherer und einfacher. 14

15 6 Nachteile 6.1 Versionsabhängigkeit Die Komponenten VServer und DRBD sind Erweiterungen des Linux Kernels. Die von den Anbietern bereitgestellten Kernel-Patches hängen meist ein oder zwei Patch-Releases hinter der aktuellen Kernel Version zurück. Somit können sicherheitsrelevante Kernel- Updates nicht sofort beim Erscheinen installiert werden. Da bisher ohne Probleme die vom Distributionsanbieter angebotenen Kernel verwendet wurden, die auch meist mehrere Patch-Releases hinter der aktuellen Kernel Version zurückhängen, wird dieses Problem als nicht kritisch eingestuft. Es wird empfohlen, den Cluster nicht im Extranet sondern nur im weniger gefährdeten Intranet zu verwenden. 6.2 Zusätzliche Host Betriebssysteme Durch die zusätzlich benötigten Host-Betriebssyteme wird der Wartungsaufwand für die Server erhöht. Dieser Aufwand wird allerdings durch die erhöhte Verfügbarkeit gerechtfertigt. Dieser zusätzliche Aufwand könnte dadurch kompensiert werden, dass Dienste die sonst auf anderen Servern laufen auf dieses sicherere System verlagert werden Kernel System Die VServer Instanzen auf den jeweiligen Host Systemen besitzen keinen eigenen Kernel. Dies führt zu Problemen bei Programmen, die direkten Zugriff auf den Kernel benötigen. Dadurch ist zum Beispiel eine Kernel-Basierte iptables Firewall für die virtuellen Linux Instanzen nicht nutzbar. 6.4 Netzwerk Spiegelung Das DRBD (siehe Abschnitt 2.3) spiegelt die Daten über das Netzwerk. Dadurch sollte eine Netzwerverbindung für die Spiegelung gewählt werden, die die einen Datendurchsatz erlaubt, der über der Datentransferrate der Festplatten liegt. Diese liegt in aktuellen Systemen bei ca. 80 MB/s. Als Netzwekadapter sollte somit mindestens ein 1 GBit/s Ethernet Adapter verwendet werden. 15