Hochverfügbare Linux-Server. Ausgabe. der 3. Auflage CLUSTERBAU: Hochverfügbarkeit. mit LINUX. Michael Schwartzkopff O REILLY

Transkript

1 Hochverfügbare Linux-Server 3. Deutsche Auflage Ausgabe der 3. Auflage CLUSTERBAU: Hochverfügbarkeit mit LINUX Michael Schwartzkopff O REILLY

2 First Inhalt Vorwort IX 1 Einleitung Hochverfügbarkeit Linux Virtual Server (LVS) Linux-HA Grundlagen Theorie Linux-Cluster Änderungen an der Clusterkommunikation Fähigkeiten der Clustersoftware Ein typischer Clusteraufbau Terminologie Architektur der Software Die Pakete Gemeinsam genutzte Daten Die Zukunft der Clustersoftware Installation und erste Konfiguration Installation unter opensuse Installation unter Fedora Installation unter RHEL, CentOS oder SLES Installation unter Debian Squeeze Installation unter Ubuntu Installation aus dem Quelltext Eine Anfangskonfiguration mit heartbeat Eine Anfangskonfiguration mit corosync Erste Eindrücke Für die Ungeduldigen: ein Mini-Cluster V

3 4 Ressourcen einrichten XML die Sprache der CIB Die globalen Einstellungen der CIB Knoten in der CIB Einfache Ressourcen Bedingungen Das Punktesystem Ressourcen für Fortgeschrittene Bedingungen für Fortgeschrittene Systemgesundheit Links 5 Verwaltung des Clusters Die GUI Die Befehle Die Subshell zum CRM Java-GUI High Availability Web Konsole (HAWK) Benutzerrechte Zukunft Planung, Aufbau und Betrieb Technische Voraussetzungen Planung Aufbau und Tests Betrieb Fehlersuche Upgrade Löschen und Austauschen von Knoten STONITH Eine weitere Applikation Weitere Hilfsprogramme Infrastruktur Stromversorgung Netzwerkanbindung Plattenspeicher Überwachung Agenten init-skripte (LSB-kompatibel) OCF-Agenten VI Inhalt

4 Rechts OCF-Agenten von pacemaker Sonstige OCF-Agenten Eigene OCF-Agenten STONITH-Agenten Beispielszenarien Die Nutzung von DRBDs DRBD: Konfiguration für Fortgeschrittene Anwendung: Ein hochverfügbarer NFS-Server Anwendung: iscsi-targets Virtuelle Rechner als Clusterressource Eine hochverfügbare Firewall mit VPN-Endpunkt Linux Virtual Server Der LVS-Director als Ressource unter pacemaker Das Director als Applikationsserver Überwachung und Sicherheit Überwachung Sicherheit A Die Konfigurationsdateien Die Konfiguration von heartbeat in ha.cf Die Konfiguration von corosync Index Inhalt VII

5 First Kapitel 1 KAPITEL 1 Hier Mini IVZ eingeben! Einleitung Erstellen auf den Arbeitsseiten (siehe Muster) Abstand untere Tabellenlinie zu Textanfang 1,8 cm -> also: manuell auf den Arbeitsseiten ziehen!!! Von der modernen Informationstechnik wird erwartet, dass alle Dienste immer verfügbar sind. Ein Reisebüro will seine Flüge 24 Stunden am Tag anbieten, und der zentrale SAP-Server der Firma muss ebenfalls immer weltweit erreichbar sein. Aber was heißt»immer«? Und wie definiert sich»dienst«genau? Was hat es mit der oft zitierten Verfügbarkeit von 99,99 % auf sich? In dieser Einleitung werden die Grundbegriffe zur Hochverfügbarkeit eingeführt und die bekanntesten Projekte unter Linux vorgestellt. Mit einfachen Berechnungsmethoden kann ein IT-Architekt die Verfügbarkeit von einfachen und zusammengesetzten, komplexen Systemen vorhersagen und ihre Schwachstellen identifizieren, bevor Fehler auftreten. Sind diese Fragen geklärt, stellt sich für den Software-, Hardware- und Netzwerkarchitekten noch das Problem, wie er die Vorgaben mit dem immer zu knappen Budget erreicht. Hochverfügbarkeit Lassen Sie uns mit den eingangs aufgeworfenen Fragen beginnen. Was heißt»immer«?»immer«heißt»zu jedem Zeitpunkt«. Wenn jemand einen Dienst anbietet, dann also zu jedem einzelnen Zeitpunkt. Aber wie lange dauert der Zeitpunkt? Und wie lange will der»kunde«den Dienst nutzen? Das hängt natürlich von der Art des Diensts und von der Vereinbarung ab, die mit dem Kunden getroffen wurde. Es ist einfach, einen Dienst für die einmalige Nutzung für eine Sekunde anzubieten. Die Wahrscheinlichkeit, dass das, was den Dienst erbringt, genau zu diesem Zeitpunkt versagt, ist relativ gering. Aber in der Informationstechnik wollen die Kunden die Dienste 24 Stunden am Tag an 7 Tagen die Woche oder genauer gesagt an 1

6 365,2425 Tagen pro Jahr 1 nutzen. Deshalb ist es ebenso wichtig, zu vereinbaren, für welchen Zeitraum der Dienst erbracht werden soll. Üblicherweise beziehen sich die Angaben von Verfügbarkeit auf Zeiträume von einem Monat oder einem Jahr. Am besten sieht man das, wenn man ein Beispiel durchrechnet: Der Anbieter will einen Dienst mit einer gewissen Verfügbarkeit A anbieten. Daraus kann man einfach folgende Tabelle 1-1 errechnen: Links Tabelle 1-1: Verfügbarkeit und Auszeit pro Monat bzw. Jahr. Eine Verfügbarkeit von 99,99 % bedeutet zum Beispiel, dass der Dienst pro Jahr maximal knapp eine Stunde nicht verfügbar ist. a Verfügbarkeit Auszeit pro Monat a Auszeit pro Jahr 99,0 % 7,2 h 87,66 h 99,5 % 3,6 h 43,83 h 99,9 % 0,72 h 8,77 h 99,99 % 4,32 min 52,59 min 99,999 % 0,43 min 5,26 min Ein Monat wird hier der Einfachheit halber mit 30 Tagen angesetzt. Damit ist aber noch nicht festgelegt, wann diese Auszeiten auftreten und wie lange sie maximal dauern dürfen. Bei der Angabe einer Verfügbarkeit von 99,5 % bezogen auf den Basiszeitraum»ein Jahr«kann eine einzelne Störung eben doch über 40 Stunden (also fast zwei Tage) dauern, wenn sonst keine weitere Störung in diesem Jahr auftritt. Die mittlere Zeit bis zur Störungsbehebung (engl. Mean Time To Repair, MTTR) ist deshalb auch eine wichtige Größe, die in einer Servicevereinbarung (Service Level Agreement, SLA) ebenfalls festgehalten werden sollte. Aus Kundensicht wäre allerdings eine Vereinbarung der maximalen Zeit zur Behebung der Störung wünschenswert. In der folgenden Tabelle 1-2 sind Größenordnungen der MTTR für einen Ausfall der Hardware dargestellt in Abhängigkeit vom Betriebsaufwand, mit dem man den Dienst betreibt. Sie zeigt, dass die Wiederherstellungszeit klar von den Kosten für den Betrieb abhängt. Dasselbe gilt für Ausfälle, die durch Softwarefehler verursacht werden: Je mehr Aufwand in den Betrieb investiert wird, desto geringer ist die mittlere Zeit bis zum Wiederanlaufen des Diensts (siehe Tabelle 1-3) Tage/Jahr + 0,25 Tage/Jahr (Schaltjahre) 0,01 (Jahre, die glatt durch 100 teilbar sind, sind keine Schaltjahre) + 0,0025 Tage/Jahr (durch 400 teilbare Jahre sind Schaltjahre) 2 Kapitel 1: Einleitung

7 Rechts Tabelle 1-2: Größenordnungen für die Wiederherstellungszeit eines Diensts beim Ausfall einer Hardwarekomponente in unterschiedlichen Betriebskonzepten. Je aufwendiger der Betrieb gestaltet wird, desto kürzer ist auch die Zeit bis zum Neustart des Diensts. Ersatzteile Personal Größenordnung für die MTTR Vor Ort 24 h/tag 30 Minuten Vor Ort Rufbereitschaft 2 Stunden Vor Ort Normale Arbeitszeit 3 Tage (Wochenende!) Kurierdienst Rufbereitschaft 1 Woche Kurierdienst Techniker wird bestellt 2 Wochen Das schnelle Wiederanlaufen des Diensts wird in Tabelle 1-3 durch automatisierte Systeme zur Erkennung des Fehlerfalls und zur Problembehebung durch Neustart erreicht. Tabelle 1-3: Größenordnungen für die Wiederherstellungszeit eines Diensts bei einem Fehler der Software. Nur wenn Problemdiagnose und -behebung automatisiert sind, lassen sich wirklich kurze Zeiten erreichen. Mechanismus zur Fehlererkennung Mechanismus für den Neustart Größenordnung der MTTR Monitoring-System Automatischer Neustart von ROM- 30 Sekunden Abbild Monitoring-System Automatischer Neustart des Diensts 30 Sekunden ohne Neustart des Systems Monitoring-System Automatischer Neustart des gesamten 3 Minuten Systems Monitoring-System Automatischer Neustart des Systems und Wiederherstellung durch Herunterladen von einem Zentralsystem 10 Minuten Keine automatische Fehlererkennung Manueller Neustart min. 30 Minuten Noch eine wichtige Größe in diesem Zusammenhang ist die mittlere Zeit zwischen zwei Ausfällen. Im Englischen heißt diese Zeit Mean Time Between Failures und wird mit MTBF abgekürzt. Diese MTBF ist eine übliche Größenangabe bei Hardwarekomponenten. Bei neuen Komponenten ist hier ebenfalls die Zeit bis zum erstmaligen Ausfall gemeint (engl. Mean Time To Failure, MTTF). In Datenblättern von Festplatten ist sie zum Beispiel meist mit angegeben. Der Vergleich der MTBF- Werte zeigt auch, warum eine SCSI-Festplatte (SAS) für einen Server so viel mehr kostet als eine SATA-Festplatte für einen Desktop-Rechner. Natürlich gelten diese Angaben der mittleren Zeiten bis zum Fehler (MTBF) immer nur für eine große Anzahl von Geräten. Von dem Ausfall einer Festplatte im Rechner zu Hause kann man nicht auf einen Fehler in der Produktion oder im Design Hochverfügbarkeit 3

8 schließen. Nur wenn sich Fehler beim Test einer ganzen Charge von Festplatten häufen, muss der Hersteller aufmerksam werden. Die Verfügbarkeit (engl. Availability) errechnet sich aus den oben gegebenen Größen als Verhältnis der Zeit, in der das System funktioniert (also kein Fehler vorliegt), zur Gesamtzeit, die betrachtet wird: Links A = MTBF (MTBF + MTTR) Die in Tabelle 1-1 angegebene Auszeit (engl. Downtime), die intuitiv am besten erfassbare Größe, lässt sich leicht aus der Verfügbarkeit A ableiten: Ausszeit = (1 A) Basiszeitraum Der Basiszeitraum ist dabei die Zeit, die im SLA vereinbart wurde, meistens ein Monat oder ein Jahr. Bei der konkreten Berechnung ist auch zu beachten, ob ein Kalendermonat als Abrechnungszeitraum oder»die letzten 30 Tage«betrachtet werden. Was heißt»dienst«? Jeder versteht unter dem Begriff»Dienst«etwas anderes. Ein Provider (ISP) und sein Kunde werden in erster an die Möglichkeit des Transports von IP-Paketen zwischen Hausanschluss und beliebigen anderen Hosts im Internet denken. Der Kunde, der einen Rootserver in einem Rechenzentrum gemietet hat, will dazu noch eine ausfallsichere Stromversorgung, eine funktionierende Klimaanlage und vielleicht ein Backup-System, wogegen der Webhoster sich auch noch um die entsprechende Applikation kümmern muss. Der Internetnutzer, der bei seiner Bank seinen Kontostand überprüft oder gerade etwas ersteigert, will, dass sein Internetanschluss funktioniert, dass alle Router bei den verschiedenen Providern funktionieren, der Server der Gegenseite und die Applikation, die er gerade nutzen will, zum Beispiel der Webserver und die Datenbank, auf die dieser zurückgreift. Natürlich muss sein Rechner zu Hause auch noch funktionieren, damit er erfährt, dass er mit dem gerade ersteigerten Wunschtraum sein Konto endgültig in die roten Zahlen gebracht hat. So versteht jeder Nutzer ein bisschen etwas anderes unter»dienst«, und der Begriff wird meist erst im Kontext verständlich. Wenn das»internet nicht geht«, kann das viele Ursachen haben, aber der Benutzer merkt nur, dass er nicht mehr surfen kann. Es kann daran liegen, dass gerade ein Bagger die Leitung vor seinem Haus durchtrennt hat oder dass der Provider ein Problem mit der Authentifizierung des Kunden hat, weil der RADIUS-Server Schwierigkeiten macht. Im Weiteren werde ich versuchen, den Begriff»Dienst«im Sinne von»dienst, den eine Applikation erbringt, die auf einem Rechner läuft«zu verwenden. Wenn diese 4 Kapitel 1: Einleitung

9 Rechts Definition nicht überall durchgehalten wird, sollte zumindest der Sinn aus dem Kontext heraus klar werden. Gekoppelte Systeme Wie oben dargestellt wurde, müssen viele einzelne Komponenten zusammenspielen, damit ein Server einen Dienst erbringen kann und die Kommunikation zwischen Client und Server auch funktioniert. Die Stromversorgung für den Server (oder gleich das ganze Rechenzentrum) ist ein schönes Beispiel. Die konstante Energiezufuhr ist eine der wesentlichen Voraussetzungen für das Funktionieren des Diensts. Zwar ist die Stromversorgung in Deutschland eine der sichersten der Welt, aber wie die Zahlen zeigen (siehe Tabelle 1-4), kann man sich auch nicht zu 100 % auf sie verlassen. Tabelle 1-4: Versorgungssicherheit mit elektrischer Energie. Die Zahlen stammen vom Electric Power Research Institute (EPRI). Durchschnittliche Ausfallzeit Verfügbarkeit Japan 6 Minuten > 99,99 % Deutschland 23 Minuten > 99,99% Frankreich 53 Minuten 99,99% Großbritannien 70 Minuten 99,98% USA 214 Minuten 99,96% Wer im Durchschnitt einen Dienst mit mehr als den oben genannten Zahlen anbieten will, muss eine unterbrechungsfreie Stromversorgung mit einplanen. Grundsätzlich ist eine solche Stromversorgung auch deshalb sinnvoll, weil ein abrupteres Ausschalten noch keinem Server gutgetan hat und allein die Zeit zum Überprüfen der Festplatten und Anlaufen der Dienste die Zeit der meist sehr kurzen Probleme der Stromversorgung bei Weitem übersteigt. Aber das Beispiel Stromversorgung zeigt noch etwas anderes: Der Dienst ist vom Funktionieren vieler einzelner Komponenten abhängig. Damit eine Applikation auf einem Server laufen kann, müssen zum Beispiel die Stromversorgung, die Hardware mit Prozessor, RAM und Festplatte, das Betriebssystem und die Applikation selbst funktionieren. Damit die Daten vom Client zum Server und zurück transportiert werden können, müssen die Netzwerkschnittstellen der beteiligten Rechner, die Kabel, Switches, Router, Firewalls und alle weiteren Netzwerkkomponenten dazwischen in Ordnung sein. Kann man aus der einfachen Formel von oben jetzt die Verfügbarkeit von komplexen Systemen herleiten? Grundsätzlich: Ja! Denn man kann jedes noch so komplexe System auf einfache Bausteine zurückführen, die untereinander nur auf zwei unterschiedliche Arten verschaltet sind. Hochverfügbarkeit 5

10 First Hier Mini IVZ eingeben! Index Erstellen auf den Arbeitsseiten (siehe Muster) A AFR (Annual Failure Rate) 8 agentx 377 Anfangskonfiguration 50 Annual Failure Rate 8 Anordnung 81, 95 AoEtarget 225 apache 226 apcmaster 291 apcmastersnmp 292 apcsmart 292 apiauth 385 ARP Reply 32 arp_announce 365 arp_ignore 365 asterisk 228 attrd_updater 141 Attribute 72 AudibleAlarm 229 Ausdruck 85 authkeys 52 auto_failback 388 autojoin 389 B batch-limit 67 baud 387 baytech 292 bcast 387 Bedingungen 80 Erreichbarkeit 104 Knoten-Attribute 99 komplexe 95 Multi-State-Resourcen 98 zeitliche Vorgaben 100 Abstand untere Tabellenlinie zu Textanfang 1,8 cm -> also: manuell auf den Arbeitsseiten ziehen!!! Befehle 128 Beispiele 307 DRBD 308 dual primary 320 Betrieb 180 bindnetaddr 394 broadcast 394 C CCM 36 CIB 36 globale Einstellungen 63 cibadmin 132 clear_node_high_bit 395 Cluster Information Base 36 Cluster Resource Manager 35 Clusteraufbau 31 cluster-delay 67 cluster-glue 27 cluster-infrastructure 69 ClusterMon 229 cluster-recheck-interval 69 Clustersoftware Fähigkeiten 29 colocation 83 Co-Lokation 83 compression 392 compression_threshold 392 conn_logd_time 392 conntrackd 351 consensus 396 Consensus Cluster Membership 36 coredumps 392 CRM 35, 151 crm 63,

11 Links crm_attribute 142 crm_diff 143 crm_failcount 139 crm_mon 128 crm_resource 136 crm_shadow 145 crm_standby 140 crm_verify 135 cyclades 292 external/rackpdu 297 external/riloe 297 external/sbd 298 external/ssh 298 external/vmware 299 external/xen0 299 external/xen0-ha 299 F D Data Sharing 23 Daten-Replikation 23 db2 232 DC 34 dc-deadtime 69 dc-version 69 deadping 391 deadtime 386 debug 391, 398 debugfile 386 default-action-timeout 67 default-resource-stickiness 64 Delay 233 Designated Coordinator 34 Director 10, 359 direktes Routing 12 downcheck 396 dpdaction 355 dpddelay 355 dpdtimeout 355 drac3 293 drbd 233 Dummy 234 fail_recv_const 396 failure-timeout 73 Fehlersuche 181 Fencing 22 fileline 398 Filesystem 239 Firewall 343 fwbuilder 347 G Gemeinsame Daten 23 Gruppe 88 GUI 112 Anordnungen 124 Bedingungen 124 Co-Lokationen 125 Gruppe 121 Klone 122 Knoten 115 Linbit 162 Management 116 Multistate Ressourcen 123 Platzierungen 126 Ressourcen 118 Übersicht 113 E edir Evmsd 237 EvmsSCC 238 expected-quorum-votes 69 expression 85 Extended Markup Language 61 external/drac5 293 external/hmchttp 294 external/ibmrsa 294 external/ibmrsa-telnet 294 external/ipmi 295 external/kdumpcheck 295 H ha.cf 50 Hardware 173 haresources 52 hb_report 194 hbaping 390 hbgenmethod 391 #health 109 health 109 heartbeat Anfangskonfiguration 50 Start Index

12 Rechts heartbeat_failures_allowed 397 Hochverfügbarkeit 1 hold 396 hopfudge 391 I ibmhmc 300 ICP 240 ids 240 -INFINITY 80 INFINITY 80 initdead 387 init-skripte 220 Installation CentOS 44 Fedora 43 opensuse 42 RHEL 44 SLES 44 Ubuntu 46 ip_vs 360 IPaddr 241 IPaddr2 242 ipmilan 300 IPsec 354 IPsrcaddr 244 IP-Tunnel 13 ipvsadm 362 IQN 247, 330 iscsi 245 iscsi Enterprise Target 330 iscsi Qualified Name 247, 330 iscsi-initiator 332 iscsilogicalunit 245 iscsi-target 246, 329 iscsitarget 246 is-managed-default 65 J join 396 K keepalive 356, 386 Kerberos 328 Klasse 71 Klone 90 Knoten 19, 33, 70 Konfiguration, Synchronisation 357 Kopplung Parallel 6 Seriell 6 KVM 333 Installation 334 L ldirectord 248, 360, 366 libvirt 334 Installation 334 Linux Virtual Server 10, 359 Linux-HA 15 Version 1 24 Version 2 26 LinuxSCSI 249 Live Migration 339 Load-Sharing 243 Local Resource Manager 36 location 84 logfacility 386 logfile 386, 398 Löschen von Knoten 187 LRM 36 LSB 220 LUN 245 LVM 249 LVS 10 M MailTo 250 maintenance-mode 65 ManageRAID 251 ManageVE 252 max_messages 397 max_network_delay 397 mcast 387 mcastaddr 394 mcastport 394 Mean Time Between Failures 3 Mean Time To Repair 2 meatware 301 member 394 merge 396 Migration von Ressourcen 94 migration-threshold 72 miss_count_const 397 msgfmt 391 Index 401

13 Links MTBF 3 MTTR 2 multiple-active 72 Multi-State-Ressourcen 92 mysql 252 mysql-proxy 254 N nagios 380 NAS 24 NAT 11 netmtu 395 Netzwerk-Management 375 NFS-Server 323 nfsserver 255 node 389 node-health-green 68 node-health-red 68 node-health-strategy 68 node-health-yellow 68 nodeid 395 no-quorum-policy 63 ntp 50 nw_rpc100s 301 O OCF-Agenten 221 controld 283 eigene 285 pacemaker 282 ocf-tester 196 op_defaults 76 OpenAIS 28 Anfangskonfiguration 53 Start 57 OpenS/WAN 354 open-scsi 330 OpenVPN 355 Operationen 76 Operator 85 oracle 257 oralsnr 259 ordering 81 P pacemaker Historie 26 pe-error-series-max 68 pe-input-series-max 68 Persistent Connection 11 pe-warn-series-max 68 pgsql 259 ping 260, 389 ping_group 390 placement-strategy 68 Planung 177 Platzierung 84 Policy Engine 35 portblock 261 priority 72 ptest 147 Pure-FTPd 263 Q Quelltext 46 Quorum 21, 34 R RAID 7 Raid1 263 rcd_serial 301 realtime 391 Red Hat Enterprise Linux (RHEL) 44 Redundant Array of Inexpensive Disks 7 Redundanz 6 Regeln 85 remove-after-stop 67 Resource Agent 33 respawn 390 Ressource 19, 20, 33, 61 einfache 70 komplexe 88 retransmits_before_loss 396 ringnumber 394 Route 264 rps1 302 rrp_mode 395 rrp_problem_count_threshold 397 rrp_problem_count_timeout 397 rrp_token_expired_timeout 398 rsc_colocation 83 rsc_defaults 76 rsc_location 84 rsc_order 81 rsyncd 264 rtprio Index

14 Rechts S T SAN 24 SAPDatabase 268 SAPInstance 265 scsi2reservation 269 secauth 395 send_join 396 SendArp 270 seqno_inchanged_const 397 serial 387 ServeRAID 270 Service Level Agreement 2 sfex 271 shutdown-escalation 69 Sicherheit 382 Single-Point-of-Failure 7 SLA 2 SNMP 376 SNMP-Subagent 377 SNMP-Trap 381 Software 176 SphinxSearchDaemon 273 Split-Brain 21, 34 SPoF 7 Squid 273 start-failure-is-fatal 66 startup-fencing 66 Stateful 274 STONITH 34, 189 Beispiele 303 stonith 288, 388 stonith-action 66 STONITH-Agenten 288 stonith-enabled 66 stonith-timeout 66 STONITHstonith 392 STONITHstonith_host 388 stop-all-resources 67 stop-orphan-actions 67 stop-orphan-resources 67 Subshell 151 suicide 302 symmetric-cluster 64 SysInfo 79, 274 syslog_facility 398 Systemgesundheit 109 target-role 72 Test 179 threads 395 timestamp 398 to_file 398 to_stderr 398 to_syslog 398 token 396 token_retransmit 396 tomcat 276 traditional_compression 392 transport 395 U Überwachung 375 Fehlerzähler 381 ucast 388 udpport 387 Upgrade 184 Disconnect und Reattach 186 use_logd 391 uuidfrom 392 V Verbindungstabellen 351 Verfügbarkeit 4 Vergleich 85 version 394 Verwaltung 111 VIPArip 278 VirtualDomain 278 Virtuelle Rechner Überwachung 338 vmware 279 Vorbereitung 176 VPN 354 vsftype 395 W warntime 386 WAS 279 WAS6 280 watchdog 389 Webserver 78 window_size 397 WinPopup 280 wti_nps 303 Index 403

15 X Xen 280 Xinetd 281 XML 61 Z Zeitabgleich 50, 177 Links 404 Index