Hochverfügbare Virtualisierungsumgebung mit Red Hat Enterprise Virtualization und Distributed Replicated Block Device

Hochverfügbare Virtualisierungsumgebung mit Red Hat Enterprise Virtualization und Distributed Replicated Block Device Lukas Grimm Puzzle ITC grimm@puzzle.ch 6. März 2014

INHALTSVERZEICHNIS INHALTSVERZEICHNIS Inhaltsverzeichnis 1 Einleitung 3 1.1 Ziel dieser Anleitung............................... 3 1.2 Voraussetzungen................................. 3 2 Software 4 2.1 Software Repositories.............................. 4 2.1.1 DRBD und Pacemaker Repositories.................. 4 2.2 EPEL-Repository................................ 5 3 DRBD 6 3.1 Installation.................................... 6 3.2 Konfiguration.................................. 6 3.3 Installation und Konfiguration via Puppet................... 7 3.3.1 harhev.pp................................ 7 3.3.2 cluster.pp................................ 8 3.3.3 linbit.pp................................. 8 4 KVM Maschine definieren 8 5 Pacemaker und Heartbeat 9 5.1 Installation.................................... 9 5.2 Konfiguration Heartbeat............................. 10 5.3 Allgemeine Pacemakerregeln.......................... 10 5.4 Pacemakerregeln für den Manager....................... 12 6 Pacemakerregeln für iscsi 13 6.1 Pacemaker und Puppet............................. 14 7 RHEV Installation 15 7.1 Installation RHEV-Manager........................... 15 7.2 LVM-Rekonfiguration.............................. 16 7.3 Erweiterung zur udev-regel für DRBD..................... 16 7.4 Hypervisor Installation.............................. 17 7.4.1 RHEV-Powermanagement........................ 17 7.5 Anpassungen an libvirt............................. 18 7.6 Zweite Hypervisor Installation.......................... 18 8 Storage Installlation 18 9 Testen 19 1

ABBILDUNGSVERZEICHNIS ABBILDUNGSVERZEICHNIS Abbildungsverzeichnis 1 Hinzufügen eines Hosts in RHEV........................ 17 2 Hinzufügen von iscsi-storage in RHEV.................... 19 2

1 EINLEITUNG 1 Einleitung Dieses Dokument entstand im Rahmen der Abschlussarbeit meiner Informatiker-Lehre und ist Bestandteil der Projekt-Dokumentation. Dieses Dokument basiert auf High-Availability ovirt-cluster with iscsi-storage von Benjamin Alfery und Philipp Richter, 2013 LINBIT HA-Solutions GmbH. 1.1 Ziel dieser Anleitung Diese Anleitung soll Schritt für Schritt aufzeigen, wie man aus zwei physikalischen Maschinen eine hochverfügbare Virtualisierungsumgebung aufbauen kann. Diese basiert auf einer virtuellen Maschine, auf welcher der RHEV-Manager läuft und einem iscsi-target als Speicher für die virtuellen Maschinen des RHEVs. Die beiden Maschinen dienen gleichzeitig als RHEV- Hypervisoren. Für die Replizierung der Daten der KVM-Maschine und des iscsi-targets wird DRBD verwendet. Für das Cluster-Management wird Pacemaker und Heartbeat eingesetzt. 1.2 Voraussetzungen Diese Dokumentation geht von zwei physischen Maschinen aus, welche harhev1 und harhev2 genannt werden. Diese sind am lokalen Netz mit den IP-Adressen 10.1.0.6 und 10.1.0.7 sowie über einen Crossover-Link mit den IP-Adressen 192.168.10.10 und 192.168.10.11. Da RHEV bei den Hypervisor eine Bridge verwendet, macht es Sinn, die IP-Adressen für das lokale Netzwerk gleich über die Bridge rhevm (oder ovirtmgmt falls ovirt verwendet wird) laufen zu lassen. DRBD wird die Nummern 0 (Ressourcenname: kvm-ovirtm) und 1 (Ressourcenname: iscsi) für die replizierten Volumen verwenden. Dieses Dokument beschreibt eine RHEV/iSCSI/DRBD/Pacemaker Installation auf einer x86 64 Maschine mit Red Hat Enterprise Linux 6.5 mit Kernel Version 2.6.32-431.5.1.el6.x86 64 und DRBD Version 8.4.4. Weiter wird davon ausgegangen, dass LVM verwendet wird. Auch wenn LVM nicht zwingend ist, wird LVM wegen seiner Flexibilität empfohlen. Für die später gebrauchten Ressourcen sollten zwei LVs auf beiden Nodes erstellt werden: 1 l v c r e a t e L20G n kvm ovirtm system # f ü r d i e v i r t u e l l e Maschine a u f w e l c h e r d e r Manager l ä u f t 2 l v c r e a t e L500G n i s c s i system # S t o r a g e f ü r d i e v i r t u e l l e n Maschinen welche im RHEV e r s t e l l t werden, Grö s s e e n t s p r e c h e n d anpassen Es wird davon ausgegangen, dass der Leser Linux, DRBD und Pacemaker Wissen besitzt. 3

2 SOFTWARE 2 Software Es wird davon ausgegangen, dass die Systeme bereits aufgesetzt sind und am Red Hat Network angemeldet sind. Für ein Setup via Puppet ist zu beachten, dass für die Abhängigkeiten von Puppet der RHEL Server Optional Channel angehängt sein sollte. Pacemaker ist ein Cluster Ressourcen Management Framework, welches gebraucht wird, um Ressourcen zu starten, zu stoppen, zu überwachen und zu migrieren. Es wird von Pacemaker 1.1.6 ausgegangen. Heartbeat ist eine Cluster-Benachrichtigungs-Ebene, welche von Pacemaker verwendet wird. Es wird von Heartbeat 3.0.5 ausgegangen. DRBD ist eine Netzwerkspeicherlösung welche verwendet wird um auf Blockdevice-Ebene Daten zu synchronisieren. Kompilierte Pakete sind im Linbit Repository enthalten. Es werden die Pakete drbd-utils und drbd-kmod gebraucht, welche die DRBD Administrationswerkzeuge und das Kernel Modul zur Verfügung stellen. Libvirt ist ein opensource Management Tool für Virtualisierung. Libvirt liefert eine API zu verschiedenen Virtualisierungstechnologien wie KVM, QEMU, XEN und VMware ESX. RHEV/RHEVM ist eine Management-Applikation für virtuelle Maschinen. Diese Anleitung wurde für die Version 3.3 erstellt, sollte jedoch auch mit 3.2 laufen. 2.1 Software Repositories Ausgehend davon, dass das Betriebsystem komplett installiert und aktuell ist sowie die beiden Netzwerkinterfaces korrekt konfiguriert sind und funktionieren, ist der erste Schritt auf beiden Maschinen, die Linbit Repositories hinzuzufügen. Dies kann mit dem yum Puppet Modul 1 mit folgenden zusätzlichen Manifesten bewerkstelligt werden: 2.1.1 DRBD und Pacemaker Repositories Linbit DRBD-Repository: 1 # l i n b i t drbd r e p o s i t o r y 2 c l a s s yum : : r e p o s : : l i n b i t d r b d ( 3 $ l i n b i t d r b d a c c e s s h a s h = <hash> 4 ) { 5 yum : : managed yumrepo { 6 l i n b i t d r b d : 7 d e s c r => RHEL 6 L i n b i t DRBD 8. 4, 8 b a s e u r l => h t t p : / / packages. l i n b i t. com/${ l i n b i t d r b d a c c e s s h a s h }/8.4/ r h e l 6 / x86 64, 9 e n a b l e d => 1, 10 gpgcheck => 0, 11 p r i o r i t y => 1 ; 12 } 13 } 1 http://puppet-modules.git.puzzle.ch/?p=module-yum.git;a=summary 4

2.2 EPEL-Repository 2 SOFTWARE Linbit Pacemaker-Repository: 1 # l i n b i t drbd r e p o s i t o r y 2 c l a s s yum : : r e p o s : : l i n b i t p a c e m a k e r ( 3 $ l i n b i t a c c e s s h a s h = <hash> 4 ) { 5 6 yum : : managed yumrepo { 7 l i n b i t p a c e m a k e r : 8 d e s c r => RHEL 6 L i n b i t Pacemaker, 9 b a s e u r l => h t t p : / / packages. l i n b i t. com/${ l i n b i t a c c e s s h a s h }/ pacemaker / r h e l 6 / x86 64, 10 e n a b l e d => 1, 11 gpgcheck => 0, 12 p r i o r i t y => 1, 13 e x c l u d e => h e a r t b e a t, h e a r t b e a t l i b s ; 14 } 15 } Es ist sicherzustellen, dass der <hash> mit dem Hash, welcher von Linbit zur Verfügung gestellt werden, ersetzt wird. Falls man keinen Zugriff auf diesen hat, dann muss man die Installation von DRBD, pacemaker und heartbeat selber bewerkstelligen. 2.2 EPEL-Repository Es wird empfohlen, das heartbeat Paket aus dem Epel-Repo zu installieren, da bei der Version heartbeat-3.0.4-1.el6.x86 64 aus dem Linbit Repo das init Skript Fehler aufweist 2. 2 https://bugzilla.redhat.com/show_bug.cgi?id=1028127 5

3 DRBD 3 DRBD 3.1 Installation Für DRBD werden, wie bereits erwähnt, zwei Pakete gebraucht. Diese können mit yum -y install drbd kmod-drbd installiert werden. Da Pacemaker die Ressourcen verwalten soll, muss der DRBD-Service mit chkconfig drbd off deaktiviert werden. 3.2 Konfiguration Die DRBD-Ressourcen müssen auf beiden Servern konfiguriert werden. Dies macht man, indem man unter /etc/drbd.d/ eine Datei mit dem Namen der Ressource und der Endung.res anlegt. Die erste Ressource /etc/drbd.d/kvm-ovirtm.res sieht wie folgt aus: 1 r e s o u r c e kvm o v i r t m { 2 net { 3 p r o t o c o l C ; 4 } 5 volume 0 { 6 d e v i c e minor 0 ; 7 d i s k / dev / system / kvm ovirtm ; 8 meta d i s k i n t e r n a l ; 9 } 10 on harhev1 { 11 a d d r e s s 1 9 2. 1 6 8. 1 0. 1 0 : 7 7 8 8 ; 12 } 13 on harhev2 { 14 a d d r e s s 1 9 2. 1 6 8. 1 0. 1 1 : 7 7 8 8 ; 15 } 16 } Analog dazu /etc/drbd.d/iscsi.res: 1 r e s o u r c e i s c s i { 2 net { 3 p r o t o c o l C ; 4 } 5 volume 0 { 6 d e v i c e minor 1 ; 7 d i s k / dev / system / i s c s i ; 8 meta d i s k i n t e r n a l ; 9 } 10 on harhev1 { 11 a d d r e s s 1 9 2. 1 6 8. 1 0. 1 0 : 7 7 8 9 ; 12 } 13 on harhev2 { 14 a d d r e s s 1 9 2. 1 6 8. 1 0. 1 1 : 7 7 8 9 ; 15 } 16 } 6

3.3 Installation und Konfiguration via Puppet 3 DRBD Anschliessend müssen die Ressourcen mit drbdadm create-md $resource erstellt werden und mit drbdadm up $resource aktiviert werden. Dies muss auf beiden Servern ausgeführt werden. Abschliessend muss ein Server als Primary gesetzt werden, dies geschieht mit drbdadm primary force $resource. Den DRBD-Status kann mit cat /proc/drbd überprüft werden. 3.3 Installation und Konfiguration via Puppet Die Installation und Konfiguration via Puppet kann mit folgenden Puppetmanifesten bewerkstelligt werden, welche auch bald unter http://puppet-modules.git.puzzle.ch/ verfügbar sein werden. Die Aktivierung muss jedoch von Hand vorgenommen werden, damit Puppet nicht eine aktive Ressource zerstört. 3.3.1 harhev.pp 1 c l a s s drbd : : harhev { 2 i n c l u d e drbd : : c l u s t e r 3 i n c l u d e drbd : : l i n b i t 4 5 / 6 s t u f f a c t u a l l y done manually : 7 8 drbdadm c r e a t e md r e s o u r c e 9 drbdadm up r e s o u r c e 10 drbdadm p r i m a r y f o r c e r e s o u r c e 11 / 12 13 f i l e { 14 / e t c / drbd. d/kvm o v i r t m. r e s : 15 s o u r c e => puppet : / / / modules / drbd / harhev /kvm o v i r t m. r e s, 16 owner => r o o t, group => 0, mode => 0640; 17 / e t c / drbd. d/ i s c s i. r e s : 18 s o u r c e => puppet : / / / modules / drbd / harhev / i s c s i. r e s, 19 owner => r o o t, group => 0, mode => 0640; 20 } 21 } Diese Klasse legt die Konfigurationsdateien an, deren Inhalt oben beschrieben ist und deshalb hier nicht nochmal aufgeführt werden. Weiter werden zwei weitere Klassen eingebunden. 7

4 KVM MASCHINE DEFINIEREN 3.3.2 cluster.pp 1 c l a s s drbd : : c l u s t e r { 2 # e n s u r e t h a t drbd i s not e n a b l e d as s t a r t u p s e r v i c e because drbd s e r v i c e i s c o n t r o l l e d by rgmanager / pacemaker 3 s e r v i c e { drbd : 4 e n a b l e => f a l s e, 5 r e q u i r e => Package [ drbd ], 6 } Die Klasse Cluster stellt sicher, dass der DRBD-Service in einem Cluster nicht läuft, da diese Aufgabe von einem Clustermanagement-Tool wie Pacemaker übernommen wird. 3.3.3 linbit.pp 1 # c l a s s f o r s e r v e r s which use packages from l i n b i t 2 c l a s s drbd : : l i n b i t { 3 i n c l u d e yum : : r e p o s : : l i n b i t d r b d 4 5 package { drbd : 6 e n s u r e => p r e s e n t, 7 } 8 9 package { kmod drbd : 10 e n s u r e => p r e s e n t, 11 a l i a s => drbd module, 12 } 13 } Diese Klasse bindet die zuerst die Repo-Klasse, welche unter Software deklariert worden ist, ein und installiert anschliessend die notwendigen Pakete. 4 KVM Maschine definieren Auf beiden Server muss eine virtuelle Maschine erstellt werden, welche die kvm-ovirtm- DRBD-Ressource als Harddisk eingebunden hat. Die Definition sollte ähnlich der folgenden sein: 1 <domain t y p e= kvm > 2 <name>ovirtm</name> 3 <u u i d>34 ad3032 f68e 734a 8e84 47 af69e7848a</ u u id> 4 <memory u n i t= KiB >6291456</memory> 5 <currentmemory u n i t= KiB >6291456</ currentmemory> 6 <vcpu placement= s t a t i c >1</ vcpu> 7 <os> 8 <t y p e a r c h= x86 64 machine= r h e l 6. 4. 0 >hvm</ t y p e> 9 <boot dev= hd /> 10 </ os> 11 <f e a t u r e s> 12 <a c p i /> 13 <a p i c /> 8

5 PACEMAKER UND HEARTBEAT 14 <pae /> 15 </ f e a t u r e s> 16 <c l o c k o f f s e t= utc /> 17 <o n p o w e r o f f>d e s t r o y</ o n p o w e r o f f> 18 <o n r e b o o t> r e s t a r t</ o n r e b o o t> 19 <o n c r a s h> r e s t a r t</ o n c r a s h> 20 <d e v i c e s> 21 <e m u l a t o r>/ u s r / l i b e x e c /qemu kvm</ e m u l a t o r> 22 <d i s k t y p e= b l o c k d e v i c e= d i s k > 23 <d r i v e r name= qemu t y p e= raw cache= none /> 24 <s o u r c e dev= / dev / drbd /by r e s /kvm o v i r t m /0 /> 25 <t a r g e t dev= vda bus= v i r t i o /> 26 <a d d r e s s t y p e= p c i domain= 0 x0000 bus= 0 x00 s l o t= 0 x04 /> 27 </ d i s k> 28 < i n t e r f a c e t y p e= b r i d g e > 29 <mac a d d r e s s= 52 : 5 4 : 0 0 : 0 8 : 1 0 : d a /> 30 <s o u r c e b r i d g e= ovirtmgmt /> 31 <model t y p e= v i r t i o /> 32 <a d d r e s s t y p e= p c i domain= 0 x0000 bus= 0 x00 s l o t= 0 x03 /> 33 </ i n t e r f a c e> 34 < s e r i a l t y p e= pty > 35 <t a r g e t p o r t= 0 /> 36 </ s e r i a l> 37 <c o n s o l e t y p e= pty > 38 <t a r g e t t y p e= s e r i a l p o r t= 0 /> 39 </ c o n s o l e> 40 <i n p u t t y p e= t a b l e t bus= usb /> 41 <i n p u t t y p e= mouse bus= ps2 /> 42 <g r a p h i c s t y p e= vnc p o r t= 1 a u t o p o r t= y e s /> 43 <v i d e o> 44 <model t y p e= c i r r u s vram= 9216 heads= 1 /> 45 <a d d r e s s t y p e= p c i domain= 0 x0000 bus= 0 x00 s l o t= 0 x02 /> 46 </ v i d e o> 47 <memballoon model= v i r t i o > 48 <a d d r e s s t y p e= p c i domain= 0 x0000 bus= 0 x00 s l o t= 0 x05 /> 49 </ memballoon> 50 </ d e v i c e s> 51 </ domain> Es wird empfohlen, die Maschine gleich mit einem RHEL 6.5 aufzusetzen, alle weiteren Schritte zur Installation folgen später. 5 Pacemaker und Heartbeat 5.1 Installation Für Pacemaker werden die Pakete drbd-pacemaker pacemaker-hb pacemaker-hb-cli heartbeat gebraucht. Wie bereits beschrieben, wird die heartbeat am besten aus dem EPEL-Repo installiert, da bei dieser Version der init-script Bug gefixt wurde. 9

5.2 Konfiguration Heartbeat 5 PACEMAKER UND HEARTBEAT 5.2 Konfiguration Heartbeat Um die Clusterkommunikation zu ermöglichen, muss Heartbeat konfiguriert werden. Unter /etc/ha.d/ha.cf sind die Heartbeatparameter abgelegt. Diese sollten in etwa so aussehen: 1 a u t o j o i n none 2 node harhev1 3 node harhev2 4 b c a s t eth1 5 mcast rhevm 2 3 9. 1 9 2. 0. 6 1 694 1 0 6 u s e l o g d y e s 7 i n i t d e a d 120 8 deadtime 20 9 warntime 10 10 k e e p a l i v e 1 11 c o m p r e s s i o n bz2 12 crm respawn Weiter sollte im selben Verzeichnis eine Datei mit dem Namen authkeys angelegt werden, welche in etwa so aussieht: 1 auth 1 2 1 sha1 sdrsdfrgaqerbqerbq34bgaebaqejrbnsdfq23fwe Dieser Key wird als Shared-Secret für die Cluster-Kommunikation verwendet. Es ist sicherzustellen, dass diese Datei die richtigen Berechtigungen hat: 1 chown r o o t : / e t c /ha. d/ a u t h k e y s 2 chmod 600 / e t c /ha. d/ a u t h k e y s Anschliessend kann Heartbeat mit service heartbeat start gestartet werden. Es sollte sichergestellt werden, dass Heartbeat beim Systemstart gestartet wird: chkconfig heartbeat on. 5.3 Allgemeine Pacemakerregeln Als erstes sollten allgemeine Clusterkonfigurationen definiert werden. Diese können über die crm-shell auf einem Server getätigt werden. Es ist zu beachten, dass die Timeout-Zeiten entsprechend den Bedürfnissen und der Hardware angepasst werden sollten: 1 p r o p e r t y $ i d= cib b o o t s t r a p o p t i o n s \ 2 no quorum p o l i c y= i g n o r e \ 3 c l u s t e r recheck i n t e r v a l= 1min 4 5 r s c d e f a u l t s $ i d= r s c o p t i o n s \ 6 r e s o u r c e s t i c k i n e s s= 200 \ 7 m i g r a t i o n t h r e s h o l d =2 \ 8 f a i l u r e t i m e o u t =300 s 10

5.3 Allgemeine Pacemakerregeln 5 PACEMAKER UND HEARTBEAT Weiter sollte STONITH (Shoot the other node in the head) konfiguriert werden, damit im Fall eines Fehlers der Server neu gestartet werden kann. Die hier beschriebene Konfiguration geht davon aus, dass die Server ein IPMI (mit den IP-Adressen 10.1.0.4 und 10.1.0.5) besitzen: 1 p r i m i t i v e s t h a r h e v 1 s t o n i t h : e x t e r n a l / ipmi \ 2 params hostname= harhev1 i p a d d r= 1 0. 1. 0. 4 u s e r i d= ADMIN passwd= password i n t e r f a c e= l a n p l u s 3 l o c a t i o n l s t h a r h e v 1 s t h a r h e v 1 i n f : harhev1 4 5 p r i m i t i v e s t h a r h e v 2 s t o n i t h : e x t e r n a l / ipmi \ 6 params hostname= harhev2 i p a d d r= 1 0. 1. 0. 5 u s e r i d= ADMIN passwd= password i n t e r f a c e= l a n p l u s 7 l o c a t i o n l s t h a r h e v 2 s t h a r h e v 2 i n f : harhev2 Durch einen Fehler in Heartbeat wird hier eine Fehlermeldung auftreten: WARNING: l st harhev2: referenced node harhev2 does not exist. Dies liegt daran, dass Heartbeat die Node-ID mit dem Node-Namen vergleicht, anstatt den beiden Namen. Diese Meldung kann ignoriert werden. Die vorgenommenen Änderungen sollten zuerst in der crm-shell getestet werden und anschliessend mit commit scharf geschaltet werden. 11

5.4 Pacemakerregeln für den Manager 5 PACEMAKER UND HEARTBEAT 5.4 Pacemakerregeln für den Manager Als nächstes sollte die DRBD-Ressource für den Manager in Pacemaker konfiguriert werden: 1 p r i m i t i v e p drbd kvm o v i r t m o c f : l i n b i t : drbd \ 2 params d r b d r e s o u r c e= kvm o v i r t m \ 3 op monitor i n t e r v a l= 29 r o l e= Master t i m e o u t= 30 \ 4 op monitor i n t e r v a l= 30 r o l e= S l a v e t i m e o u t= 30 \ 5 op s t a r t i n t e r v a l= 0 t i m e o u t= 240 \ 6 op s t o p i n t e r v a l= 0 t i m e o u t= 100 Da diese Ressource über zwei Server spannt, braucht es ein Master/Slave-statement: 1 ms ms drbd kvm o v i r t m p drbd kvm o v i r t m \ 2 meta c l o n e node max= 1 c l o n e max= 2 master max= 1 master node max= 1 n o t i f y= t r u e Als nächstes definieren wir die virtuelle Maschine: 1 p r i m i t i v e p kvm o v i r t m o c f : h e a r t b e a t : VirtualDomain \ 2 params c o n f i g= / e t c / l i b v i r t /qemu/ ovirtm. xml \ 3 op s t a r t i n t e r v a l= 0 t i m e o u t= 180 s \ 4 op s t o p i n t e r v a l= 0 t i m e o u t= 300 s \ 5 op monitor i n t e r v a l= 60 s t i m e o u t= 60 s Da die Disk und die virtuelle Maschine auf demselben Server laufen sollen müssen noch zwei Einschränkungen definieren, die erste definiert, dass die beiden Ressourcen auf dem gleichen Server laufen: 1 c o l o c a t i o n co kvm o v i r t m w i t h d r b d +i n f : p kvm o v i r t m : S t a r t e d ms drbd kvm o v i r t m : Master Die zweite definiert die Reihenfolge, damit die Maschine erst gestartet wird, wenn die Disk bereit ist: 1 o r d e r o drbd kvm o v i r t m b e f o r e k v m +i n f : ms drbd kvm o v i r t m : promote p kvm o v i r t m : s t a r t Auch hier gilt es, die Änderungen zuerst zu überprüfen und dann zu commiten. 12

6 PACEMAKERREGELN FÜR ISCSI 6 Pacemakerregeln für iscsi Als erstes muss auch für die iscsi die DRBD-Ressource definiert werden: 1 p r i m i t i v e p d r b d i s c s i o c f : l i n b i t : drbd \ 2 params d r b d r e s o u r c e= i s c s i \ 3 op monitor i n t e r v a l= 29 r o l e= Master t i m e o u t= 30 \ 4 op monitor i n t e r v a l= 30 r o l e= S l a v e t i m e o u t= 30 \ 5 op s t a r t i n t e r v a l= 0 t i m e o u t= 240 \ 6 op s t o p i n t e r v a l= 0 t i m e o u t= 100 Da sich auch diese Ressource über zwei Server spannt, braucht es auch hier wieder ein Master/Slave-statement: 1 ms m s d r b d i s c s i p d r b d i s c s i \ 2 meta c l o n e node max= 1 c l o n e max= 2 master max= 1 master node max= 1 n o t i f y= t r u e Als nächstes wird das iscsi-target definiert: 1 p r i m i t i v e p i s c s i s t o r e 1 o c f : h e a r t b e a t : i S C S I T a r g e t \ 2 params i m p l e m e n t a t i o n= t g t i q n= i q n.2014 02 14. l i n b i t. o v i r t i s c s i : s t o r e 1 t i d= 1 \ 3 op s t a r t i n t e r v a l= 0 t i m e o u t= 60 \ 4 op s t o p i n t e r v a l= 0 t i m e o u t= 60 \ 5 op monitor i n t e r v a l= 30 t i m e o u t= 60 Dieses Target wird nun ein Lun (logical unit) zugewiesen, mit der DRBD-Ressource als Backingdevice: 1 p r i m i t i v e p i s c s i s t o r e 1 l u n 1 o c f : h e a r t b e a t : i S C S I L o g i c a l U n i t \ 2 params i m p l e m e n t a t i o n= t g t t a r g e t i q n= i q n.2014 02 14. l i n b i t. o v i r t i s c s i : s t o r e 1 l u n= 1 \ 3 path= / dev / drbd /by r e s / i s c s i /0 \ 4 op s t a r t i n t e r v a l= 0 t i m e o u t= 60 \ 5 op s t o p i n t e r v a l= 0 t i m e o u t= 60 \ 6 op monitor i n t e r v a l= 30 t i m e o u t= 60 Um vom Server unabhängig auf das definierte Target zuzugreifen, definieren wir eine Service- IP-Adresse: 1 p r i m i t i v e p i p i s c s i o c f : h e a r t b e a t : IPaddr2 \ 2 params i p= 1 9 2. 1 6 8. 1 0. 5 0 \ 3 op s t a r t i n t e r v a l= 0 t i m e o u t= 20 \ 4 op s t o p i n t e r v a l= 0 t i m e o u t= 20 \ 5 op monitor i n t e r v a l= 30 t i m e o u t= 20 13

6.1 Pacemaker und Puppet 6 PACEMAKERREGELN FÜR ISCSI Da bei es bei einem Switch- oder Failover zu tcp-reject Meldungen kommen kann, wird ein Portblock gesetzt, welcher während einem Switch alle Pakete am iscsi-port dropt. Dies ist die sicherere Variante, da dies von RHEV als Latenz-Problem verstanden wird und nicht als Fehler: 1 p r i m i t i v e p p o r t b l o c k s t o r e 1 b l o c k o c f : h e a r t b e a t : p o r t b l o c k \ 2 params i p= 1 9 2. 1 6 8. 1 0. 5 0 p o r t n o= 3260 p r o t o c o l= tcp a c t i o n= b l o c k Dieser Block muss auch wieder aufgehoben werden: 1 p r i m i t i v e p p o r t b l o c k s t o r e 1 u nblock o c f : h e a r t b e a t : p o r t b l o c k \ 2 params i p= 1 9 2. 1 6 8. 1 0. 5 0 p o r t n o= 3260 p r o t o c o l= tcp a c t i o n= unblock \ 3 op monitor i n t e r v a l= 30 s Da diese iscsi-primitives immer zusammen laufen sollen, müssen sie gruppiert werden: 1 group g i s c s i p p o r t b l o c k s t o r e 1 b l o c k p i p i s c s i p i s c s i s t o r e 1 \ 2 p i s c s i s t o r e 1 l u n 1 p p o r t b l o c k s t o r e 1 u nblock Schlussendlich müssen wiederum zwei Einschränkungen definiert werden, damit sowohl die DRBD-Ressource wie auch die Dienste auf dem selben Server laufen: 1 c o l o c a t i o n c o g i s c s i w i t h d r b d +i n f : g i s c s i : S t a r t e d m s d r b d i s c s i : Master Und damit die iscsi-dienste erst gestartet werden, wenn die DRBD-Ressource bereit ist: 1 o r d e r o d r b d i s c s i b e f o r e g i s c s i +i n f : m s d r b d i s c s i : promote g i s c s i : s t a r t 6.1 Pacemaker und Puppet Puzzle ITC ist gerade daran, ein Puppet-Modul zu Pacemaker zu schreiben. Durch den Fehler in Heartbeat, wie oben beschrieben, ist es leider noch nicht möglich, die Konfiguration via Puppet einzuspielen. Sobald dies möglich ist, wird das Modul unter http: //puppet-modules.git.puzzle.ch/ veröffentlicht und diese Anleitung entsprechend aktualisiert. 14

7 RHEV INSTALLATION 7 RHEV Installation Die Installation von RHEV wird hier aus verschiedenen Gründen nicht mit Puppet beschrieben. 7.1 Installation RHEV-Manager Für die Installation des RHEV-Manager wurde im Kapitel KVM Maschine Definieren bereits die virtuelle Maschine erstellt. Dieser Installation müssen folgende Channels angehängt werden: RHEL Server Optional RHEL Server Supplementary Red Hat Enterprise Virtualization Manager (v.3.3 x86 64) Red Hat JBoss EAP (v 6) for 6Server x86 64 Anschliessend kann mit engine-setup das Managerpaket installiert werden. Vor dem Setup der Managementengine sollte sichergestellt werden, dass die Maschine eine feste IP-Adresse hat und der DNS-Name korrekt aufgelöst wird; ansonsten wird das Setup nicht durchlaufen. Anschliessend kann mit engine-setup die Manager-Konfiguration gestartet werden. Mit config= kann eine Konfigurationsdatei eingespielt werden, ein Beispiel ist hier aufgeführt: 1 # a c t i o n=s e t u p 2 [ e n v i r o n m e n t : d e f a u l t ] 3 OVESETUP CORE/ e n g i n e S t o p=none : None 4 OVESETUP DIALOG/ c o n f i r m S e t t i n g s=b o o l : True 5 OVESETUP DB/ d a t a b a s e=s t r : e n g i n e 6 OVESETUP DB/ f i x D b V i o l a t i o n s=none : None 7 OVESETUP DB/ s e c u r e d=b o o l : F a l s e 8 OVESETUP DB/ h o s t=s t r : l o c a l h o s t 9 OVESETUP DB/ u s e r=s t r : e n g i n e 10 OVESETUP DB/ s e c u r e d H o s t V a l i d a t i o n=b o o l : F a l s e 11 OVESETUP DB/ password=s t r : y o u r d b p a s s w o r d h e r e 12 OVESETUP DB/ p o r t=i n t :5432 13 OVESETUP SYSTEM/ n f s C o n f i g E n a b l e d=b o o l : F a l s e 14 OVESETUP SYSTEM/ memcheckenabled=b o o l : True 15 OVESETUP PKI/ o r g a n i z a t i o n=s t r : example. com 16 OVESETUP CONFIG/ isodomainname=none : None 17 OVESETUP CONFIG/ adminpassword=s t r : y o u r a d m i n p a s s w o r d h e r e 18 OVESETUP CONFIG/ a p p l i c a t i o n M o d e=s t r : both 19 OVESETUP CONFIG/ f i r e w a l l M a n a g e r=s t r : i p t a b l e s 20 OVESETUP CONFIG/ u p d a t e F i r e w a l l=b o o l : True 21 OVESETUP CONFIG/ w e b s o c k e t P r o x y C o n f i g=b o o l : True 22 OVESETUP CONFIG/ fqdn=s t r : manager. example. com 23 OVESETUP CONFIG/ isodomainmountpoint=none : None 24 OVESETUP CONFIG/ s t o r a g e T y p e=s t r : i s c s i 25 OVESETUP PROVISIONING/ p o s t g r e s P r o v i s i o n i n g E n a b l e d=b o o l : True 26 OVESETUP APACHE/ c o n f i g u r e R o o t R e d i r e c t i o n=b o o l : True 15

7.2 LVM-Rekonfiguration 7 RHEV INSTALLATION 27 OVESETUP APACHE/ c o n f i g u r e S s l=b o o l : True 28 OSETUP RPMDISTRO/ r e q u i r e R o l l b a c k=none : None 29 OSETUP RPMDISTRO/ enableupgrade=none : None 30 OVESETUP AIO/ c o n f i g u r e=none : None 31 OVESETUP AIO/ storagedomaindir=none : None 32 OVESETUP DIALOG/ confirmupgrade=b o o l : True 33 OVESETUP SYSTEM/ r e d h a t S u p p o r t P r o x y P o r t=none : None 34 OVESETUP SYSTEM/ r e d h a t S u p p o r t P r o x y=none : None 35 OVESETUP SYSTEM/ r e d h a t S u p p o r t P r o x y U s e r=none : None 36 OVESETUP SYSTEM/ c o n f i g u r e R e d h a t S u p p o r t P l u g i n=b o o l : F a l s e 37 OVESETUP SYSTEM/ r e d h a t S u p p o r t P r o xypassword=none : None 38 OVESETUP SYSTEM/ r e d h a t S u p p o r t P r o x y E n a b l e d=b o o l : F a l s e 7.2 LVM-Rekonfiguration Bevor die Hypervisoren in die Engine eingebunden werden, müssen zuerst ein paar Anpassungen an der LVM-Konfiguration vorgenommen werden, da auch der Hypervisor LVM verwenden wird. Diese Anpassungen müssen auf beiden physischen Systemen angewendet werden. In /etc/lvm/lvm.conf muss write cache state=0 gesetzt werden. Beim preferred names Parameter muss der Name der Volume Group hinzugefügt werden, wenn der Name der Volume Group system ist, sieht dies wie folgt aus: 1 p r e f e r r e d n a m e s = [ ˆ/ dev /mpath/, ˆ/ dev / mapper/mpath,..., ˆ/ dev / system ] Schlussendlich muss noch der Filter um DRBD-Devices erweitert werden: 1 f i l t e r = [ r ˆ / dev / drbd. ] 7.3 Erweiterung zur udev-regel für DRBD Da die Installation der Hypervisor die qemu-konfiguration ändern wird und pacemaker auf DRBD zugreifen muss, sollte die DRBD-udev-Regel wiefolgt angepasst werden: 1 SUBSYSTEM== b l o c k, KERNEL== drbd, IMPORT{ program}= / s b i n /drbdadm sh udev minor %m, NAME= $env {DEVICE}, SYMLINK= drbd /by r e s / $env {RESOURCE} drbd /by d i s k / $env {DISK}, OWNER= vdsm, GROUP= kvm 16

7.4 Hypervisor Installation 7 RHEV INSTALLATION 7.4 Hypervisor Installation Damit die beiden physischen Server als Hypervisoren verwendet werden können, müssen noch die entsprechenden Pakete installiert werden. Dies wird vom Manager erledigt. Zuerst muss noch der Channel Red Hat Enterprise Virt Management Agent (v.6 for x86 64) angehängt werden. Danach muss der Server für pacemaker in standby versetzt werden, via crm node standby hostname. Nachdem alle Ressourcen auf dem anderen Host laufen, kann im Webinterface der Hypervisor hinzugefügt werden. Wenn man sich im Administrations-Interface einloggt, Abbildung 1: Hinzufügen eines Hosts in RHEV kann man unter dem Tab Hosts den Button new klicken und die Angaben zum neuen Host eingeben. Sobald man ok klickt, wird der Host installiert. Im unteren Bereich oder im Events Tab kann man die Istallation verfolgen. Sobald die Installation abgeschlossen wurde, wird der Host neu gestartet. 7.4.1 RHEV-Powermanagement RHEV fragt nach, ob man das Powermanagement für den neuen Host konfigurieren will oder nicht. Dieses Feature sollte im Zusammenhang mit Pacemaker mit Vorsicht genossen werden. Das Fencing von Pacemaker und das von RHEV basiert auf komplett unterschiedlichen Kriterien. Diese Konfiguration könnte, falls man keine weitere Anpassungen vornimmt, den Cluster in einen irreparablen Zustand versetzen. 17

7.5 Anpassungen an libvirt 8 STORAGE INSTALLLATION 7.5 Anpassungen an libvirt Die RHEV-Installation sichert den Zugriff auf libvirt mit einem Passwort. Jedoch muss für die virtuelle Maschine, auf der der Manager läuft, Zugriff auf libvirt gewährleistet sein. Dies kann erreicht werden, indem für Pacemaker ein Passwort gesetzt wird. Dies muss mit saslpasswd2 -a libvirt pcmk erstellt werden und dann unter /etc/libvirt/auth.conf abgelegt werden: 1 [ c r e d e n t i a l s pcmk ] 2 authname=pcmk 3 password=your password from s a s l p a s s w d 2 4 [ auth l i b v i r t o v i r t hyp1 ] 5 c r e d e n t i a l s=pcmk 6 [ auth l i b v i r t o v i r t hyp2 ] 7 c r e d e n t i a l s=pcmk 8 [ auth l i b v i r t l o c a l h o s t ] 9 c r e d e n t i a l s=pcmk Ob die Authentifizierung funktioniert, kann zum Beispiel mit virsh list getestet werden; falls kein Passwort gefragt wird, funktioniert diese wie gewünscht. 7.6 Zweite Hypervisor Installation Für die Installation des zweiten Hypervisors müssen zuerst wiederum alle Ressourcen verschoben werden. Es muss sichergestellt werden, dass beide DRBD-Ressourcen wieder synchronisiert sind. Danach kann der Host in standby gesetzt werden und anschliessend wiederum übers Management-Interface installiert werden. Nach dem reboot ist wiederum das Passwort für libvirt zu setzen, danach kann der Host wieder online genommen werden. 8 Storage Installlation Als nächster Schritt folgt das Einbinden des iscsi-storage ins RHEV. Auch dieser Schritt kann wieder über das Administrations-Portal erledigt werden. Unter dem Tab Storage kann via New Domain neuer Speicherplatz hinzugefügt werden. Für das Einbinden des iscsi- Targets muss man zuerst einen Namen wählen. Danach kann unter Adress die IP-Adresse, welche als Pacemaker-Ressource definiert wurde, eingegeben werden. Mit Discover werden die verfügbaren Targets aufgelistet. Wenn man sich beim entsprechenden Target einloggt, kann die LUN ID ausgewählt werden. Anschliessend sollte die Aktion mit OK bestätigt werden. Nach kurzer Zeit sollte die Storage-Domain auf Active wechseln. Somit sind alle relevanten Komponenten bereit zur Nutzung. 18

9 TESTEN Abbildung 2: Hinzufügen von iscsi-storage in RHEV 9 Testen Diese Anleitung beschreibt lediglich einen einfachen Aufbau eines High Availability Clusters mit RHEV. Dieser Aufbau ist keineswegs für produktive Umgebungen gedacht! Zuerst müssen entsprechende Tests, wie zum Beispiel des Fencens durchgeführt werden. Auch zu beachten ist, dass DRBD nicht als Backup missverstanden werden darf. 19