From Fedora Project Wiki
(16 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{lang|en|de|page=Opensharedroot/de}}
{{lang|en|de|page=Opensharedroot/}}


'''Open Sharedroot'''
'''Open Sharedroot'''
Line 5: Line 5:
== Einführung/Zusammenfassung ==
== Einführung/Zusammenfassung ==


Das ''open sharedroot project'' dient dazu mehrere Linux-Systeme mit einem root-File-System zu benutzen. Insbesondere Cluster-Systeme deren Nodes sich ein gemeinsames root-File-System teilen. Der Sinn dahinter ist, das die Arbeit für die Syncronisierung der Nodes weg fällt. So Teilen sich z.B. alle nodes die Apache-Konfiguration. Wenn auf einem Node die Apache-Konfiguration geändert wird, muss diese Änderung nicht auf den anderen Nodes nachgezogen werden. Die Host-Abhängigen-Dateien werden mittels CDSL eingehangen.
Das ''open sharedroot project'' dient dazu mehrere Linux-Systeme mit einem Root-File-System zu benutzen. Ins besondere Cluster-Systeme deren Nodes sich ein gemeinsames Root-File-System teilen. Der Sinn dahinter ist, das die Arbeit für die Syncronisierung der Nodes weg fällt. So teilen sich z.B. alle Nodes die Apache-Konfiguration. Wenn auf einem Node die Apache-Konfiguration geändert wird, muss diese Änderung nicht auf den anderen Nodes nachgezogen werden. Die Hostabhängigen-Dateien werden mittels CDSL eingehängt.


 
Folgende File-Systeme werden vom  ''open sharedroot project'' unterstützt:
Folgende File-Systeme werden vom  ''open sharedroot project'' unterstüzt:


* NFSv3, NFSv4
* NFSv3, NFSv4
* GFS2
* GFS2
* Ocfs2
* Ocfs2
* Ext3 als lokales filesystem
* Ext3 als lokales Filesystem


''open sharedroot cluster'' besteht aus drei Hauptkomponenten:
''open sharedroot cluster'' besteht aus drei Hauptkomponenten:


# Einem angepassten initrd (com.oonics-bootimage) um das System zu booten, da es einige Anpassungen braucht, um von einem Cluster-File-System booten zu können.
# Zum Teil angepasste Cluster-Dienste für die Cluster-Funktionalität. Diese Tools sind als ''com.oonics-Cluster Suite'' zusammengefasst..
# com.oonics-cdsls Ein Tool zum erstellen der cdsl Struktur (context dependent symbolic links). Das cdsl Konzept basiert auf bindmounts.


# Einem angepassten initrd (comoonics-bootimage) um das System zu booten, da es einige Anpassungen braucht, um von einem Cluster-File-System booten zu können.
== Getestete Distributionen ==
# Zum Teil angepasste Cluster-Dienste für die Cluster-Funktionalität. Diese Tools sind als ''comoonics-clustersuite'' zusammengefasst..
# comoonics-cdsls Ein Tool zum erstellen der cdsl Struktur (context dependent symbolic links). Das cdsl Konzept basiert auf bindmounts.
 
== Getestete Distrebutionen ==


* RHEL5  
* RHEL5  
Line 29: Line 27:
* Fedora 12
* Fedora 12
* Fedora 14
* Fedora 14


== Beispiel-Konfiguration/Installation ==
== Beispiel-Konfiguration/Installation ==
Line 35: Line 32:
=== Übersicht ===
=== Übersicht ===


Es wird Eine Fedora 14 als KVM-Wirt-System installiert. Dieser Wird-Server dient auch als DHCP-Server und als TFTP-Server. Hier werden als zwei Virtuelle Machienen, zwei Nodes installiert. Diese ist natürlich kein hochverfügbare Lösung, sondern dient nur dazu das Grundprinzip zu demonstrieren ohne teure Hartware haben zu müssen. Wenn die beiden Nodes auf eigener Hartware laufen und auf ein richtiges HA-Storage zugreifen, hätte man aber eine richtige HA-Lösung.
Es wird ein Fedora 14 als KVM-Wirt-System installiert. Dieser Wirt-Server dient auch als DHCP-Server und als TFTP-Server. Hier werden als zwei virtuelle Maschinen, (als zwei Nodes) installiert. Dies ist natürlich keine hochverfügbare Lösung, sondern dient nur dazu, das Grundprinzip zu demonstrieren ohne teure Hardware bereitstellen zu müssen. Würden die beiden Nodes auf eigener Hardware laufen und auf ein richtiges HA-Storage zugreifen, hätte man eine richtige HA-Lösung.


=== Wirt-System und Infrastruktur ===
=== Wirt-System und Infrastruktur ===


# Ein Ferora normal installieren KVM mit der als Wirt-System dienen kann. Standardmäßig ist KVM so konfiguriert das alle V-Maschinen mit einer 192.168.122.* nach Draußen geroutet wird.
Eine normale Fedora Installation mit KVM dient als Wirt-System. Standardmäßig ist KVM so konfiguriert dass alle Gastsysteme mit einer internen IP (192.168.122.*) via NAT nach draußen geroutet werden.
 
Auf dem Wirt-System sollten zwei virtuelle Gäste installiert werden. Jeder der beiden repräsentiert eine Node.
 
=== Vorbereitung NFS und PXE ===
 
Es müssen DHCP/TFTP/PXE so eingerichtet werden, dass die Nodes später damit booten können.
 
In der Datei /etc/exports wird das Verzeichnis eingetragen welches als NFS-Root-Filesystem dienen soll. Beispiel-Konfiguration:
/mnt/virtual/nfsosr/fc11  192.168.1.0/255.255.255.0(rw,no_root_squash,sync,fsid=208)
 
Mit die Änderung wirksam wird, muss der Server veranlasst werden, die Konfiguration neu ein zu lesen:
 
service nfs reload


Auf dem Virt-System sollten zwei Geste installiert werden. Jeder von beiden repräsentiert ein Node.
Bei der PXE-Boot-Konfiguration ist noch einiges mehr zu beachten. Hier ist die einschlägige Dokumentation zu konsultieren.


=== Node Vorbereitung ===


=== Vorbereitung ===
Der Node von dem installiert werden soll, sollte mit einem Update auf den aktuellen Stand gebracht werden, bevor der Cluster aufgebaut wird:


Es müssen DHCP/TFTP/PXE so eingerichtet werden, das die Nodes später damit booten können.
yum update -y
 
Die Netzwerkunterstürzung von Dracut installieren:
 
yum install dracut-network


=== Installation der OSR-Pakete ===
=== Installation der OSR-Pakete ===


Zunächst muss natürlich dracut in der letzten Version installiert sein (Siehe: [[dracut]]).
Zunächst muss natürlich Dracut in der letzten Version installiert sein (Siehe: [[dracut|Dracut]]).
 


==== Die unterschiedliche Arten einen Cluster zu booten ====
==== Die unterschiedliche Arten einen Cluster zu booten ====


Es gibt prinzipiell zwei Wege das booten des Clusters zu steuern/konfigurieren.  
Es gibt prinzipiell zwei Wege das Booten des Clusters zu steuern/konfigurieren.  


# ''static initrd'':. Dem bootloader können Parameter mitgegeben werden. Diese Parameter werden über den üblichen Weg gesetzt. Entweder über die grub-Konfiguration, oder beim Booten mittels Boot-Menü (hier edit-Modus).  
# ''static initrd'': Dem Bootloader können Parameter mitgegeben werden. Diese Parameter werden über den üblichen Weg gesetzt. Entweder über die Grub-Konfiguration oder beim Booten mittels Boot-Menü (hier edit-Modus).  
# ''full featured initrd'': Beim erstellen des initrd über Dracut werden die Werte der Cluster-Konfiguration ausgelesen und initerd gespeichert. Einschließlich root-Device, Node-ID, MAC-Adresse usw.  
# ''full featured initrd'': Beim Erstellen des initrd über Dracut werden die Werte der Clusterkonfiguration ausgelesen und im initrd gespeichert, einschließlich Root-Device, Node-ID, MAC-Adresse usw.  


Der erste Weg hat den Vorteil, das das initrd nicht geändert werden muss, wenn sich die Konfiguration des Cluster ändert. Der Vorteil von zweiten Weg ist, das alle features unterstützt werden die ein OSR-Cluster bietet. Zudem kann ein boot-Konfiguration für alle Nodes benutzt werden.
Der erste Weg hat den Vorteil, dass das initrd nicht geändert werden muss wenn sich die Konfiguration des Cluster ändert. Der Vorteil des zweiten Weges ist, dass alle Features unterstützt werden die ein OSR-Cluster bietet. Zudem kann eine Boot-Konfiguration für alle Nodes benutzt werden.


==== Benötigte RPMs für ''static initrd'' ====
==== Benötigte RPMs für ''static initrd'' ====


Führe den Befehl aus:
Führe folgenden Befehl aus:


   yum install osr-dracut-module comoonics-cdsl-py
   yum install osr-dracut-module comoonics-cdsl-py


Oder installiere folgende rpms (aber jeweils letzte Version):
Oder installiere folgende RPMs (aber jeweils letzte Version):


* http://www.open-sharedroot.org/development/osr-dracut-module/osr-dracut-module-0.8-3.noarch.rpm
* http://www.open-sharedroot.org/development/osr-dracut-module/osr-dracut-module-0.8-3.noarch.rpm
Line 80: Line 95:
==== Benötigte RPMs für ''full featured initrd'' ====
==== Benötigte RPMs für ''full featured initrd'' ====


Führe den Befehl aus:
Führe folgenden Befehl aus:


   yum install osr-dracut-module comoonics-cdsl-py osr-dracut-module-cluster
   yum install osr-dracut-module comoonics-cdsl-py osr-dracut-module-cluster


Or
Oder installiere folgende RPMs (aber jeweils letzte Version):
 
Oder installiere folgende rpms (aber jeweils letzte Version):


* http://www.open-sharedroot.org/development/osr-dracut-module/osr-dracut-module-0.8-3.noarch.rpm
* http://www.open-sharedroot.org/development/osr-dracut-module/osr-dracut-module-0.8-3.noarch.rpm
Line 100: Line 113:
==== Entwickler-Versionen installieren ====
==== Entwickler-Versionen installieren ====


Wenn du die neuste Entwickler-Version benutzen möchtest, benutze unser Git-Repository: [https://github.com/Open-Sharedroot/Open-Sharedroot-Dracut github.com]
Wenn du die neueste Entwicklerversion benutzen möchtest, verwende unser Git-Repository: [https://github.com/Open-Sharedroot/Open-Sharedroot-Dracut github.com]


Verfahre dazu wie folgt:
Verfahre dazu wie folgt:
Line 107: Line 120:
  git clone git://github.com/Open-Sharedroot/Open-Sharedroot-Dracut.git
  git clone git://github.com/Open-Sharedroot/Open-Sharedroot-Dracut.git
  cd Open-Sharedroot-Dracut
  cd Open-Sharedroot-Dracut
Für '''fedora 12''':
git checkout -b fedora_15 origin/fedora_12
Für '''fedora 14''':
git checkout -b fedora_15 origin/fedora_14
Für '''fedora 15''':
git checkout -b fedora_15 origin/fedora_15
Und so weiter... Wer die letzte '''Entwicklerversion''' verwenden will, benutzt:
git checkout master
  yum remove osr-dracut-module osr-dracut-module-cluster
  yum remove osr-dracut-module osr-dracut-module-cluster
  git pull
  git pull
Line 115: Line 145:


  make uninstall
  make uninstall


=== Erstellen einer Cluster-Konfiguration ===
=== Erstellen einer Cluster-Konfiguration ===


Erstelle ein Cluster-Konfiguration-Datei im Pfad /etc/cluster/cluster.conf .  
Erstelle eine Clusterkonfigurationsdatei im Pfad /etc/cluster/cluster.conf .  


In der folgenden Beispiel-Konfiguration fehlen die valid fencing Konfigurationen. Das ist natürlich später ein mal wichtig, wenn der Cluster produktiv arbeitet soll.
In der folgenden Beispielkonfiguration fehlen die 'valid fencing' Konfigurationen. Das ist natürlich später ein mal wichtig, wenn der Cluster produktiv arbeitet soll.


     <?xml version="1.0"?>
     <?xml version="1.0"?>
Line 143: Line 172:
=== Erstellen eines ''shared root filesystem'' ===
=== Erstellen eines ''shared root filesystem'' ===


Das ''shared root filesystem'' muss - natürlich - von einem NFS exportiert werden, mit es zur Verfügung steht. Dann kann auf dem Node der für die Installation dient, das NFS eingehangen werden. Mit diesem Befehl hängen wir das '/mnt/virtual/nfsosr/fc11' als künftiges root ein.:
Das ''shared root filesystem'' muss von einem NFS exportiert werden, damit es zur Verfügung steht. Dann kann auf dem Node der für die Installation dient das NFS eingehangen werden. Mit diesem Befehl hängen wir das '/mnt/virtual/nfsosr/fc11' als künftiges Root ein.:


  mkdir /mnt/newroot/ 
   mount -t nfs 192.168.122.1:/mnt/virtual/nfsosr/fc11 /mnt/newroot/   
   mount -t nfs 192.168.122.1:/mnt/virtual/nfsosr/fc11 /mnt/newroot/   
Ab NFS 3 wird man wohl das Flag ''-o nolock'' nötig sein.
  mount -o nolock -t nfs  192.168.122.1:/mnt/virtual/nfsosr/fc11 /mnt/newroot/


Jetzt alle Daten des lokalen Systems in das (künftige) ''shared root filesystem'' kopieren:
Jetzt alle Daten des lokalen Systems in das (künftige) ''shared root filesystem'' kopieren:
Line 151: Line 185:
   cp -ax / /mnt/newroot/
   cp -ax / /mnt/newroot/
   cp /boot/*$(uname -r)* /mnt/newroot/boot
   cp /boot/*$(uname -r)* /mnt/newroot/boot


Dann müssen wir noch ein paar benötigte Verzeichnisse erstellen (wenn es sie noch nicht gibt):
Dann müssen wir noch ein paar benötigte Verzeichnisse erstellen (wenn es sie noch nicht gibt):
Line 158: Line 191:
   mkdir /mnt/newroot/sys
   mkdir /mnt/newroot/sys


Nun wird die neue cdsl-Infrastruktur auf dem ''shared root filesystem'' generiert:
Nun wird die neue cdsl-Infrastruktur auf dem ''shared root filesystem'' angelegt:


   com-mkcdslinfrastructure -r /mnt/newroot
   com-mkcdslinfrastructure -r /mnt/newroot


Dieses wird in das File-System eingehangen:
Diese wird in das Filesystem eingehangen:


   mount --bind /mnt/newroot/cluster/cdsl/1/ /mnt/newroot/cdsl.local/
   mount --bind /mnt/newroot/cluster/cdsl/1/ /mnt/newroot/cdsl.local/
Line 172: Line 205:
   mount --bind /mnt/newroot/dev /mnt/newroot/dev
   mount --bind /mnt/newroot/dev /mnt/newroot/dev
    
    
Jetzt wird in das neue ''shared root filesystem'' gewechselt und als root benutzt:
Jetzt wird in das neue ''shared root filesystem'' gewechselt und als root verwendet:


   chroot /mnt/newroot
   chroot /mnt/newroot


Das '/var' wird ''hostdependent'' (hostabhängig) gemacht (Parameter ''-a''):
Das '/var' Verzeichnis wird ''hostdependent'' (hostabhängig) gemacht (Parameter ''-a''):


   com-mkcdsl -a /var  
   com-mkcdsl -a /var  
    
    
Das  '/var/lib' wird wieder als shared(geteilt) eingerichtet (Parameter ''-s''):
Das  '/var/lib' Verzeichnis wird wieder als shared(geteilt) eingerichtet (Parameter ''-s''):


   com-mkcdsl -s /var/lib
   com-mkcdsl -s /var/lib
<--! bis hier -->


Das '/etc/sysconfig/network' wird wiederum  ''hostdependent'' gemacht:
Das '/etc/sysconfig/network' wird wiederum  ''hostdependent'' gemacht:
Line 190: Line 221:
   com-mkcdsl -a /etc/sysconfig/network
   com-mkcdsl -a /etc/sysconfig/network


Bearbeite die hostdependent network-Konfiguration und ändere den hostnames. Mit dem vorgeschlagenen Befehl öffnest du alle Netzwerk-Konfigurationen auf ein mal. Um in vi zu nächsten Datei zu gelangen drückst du ''Esc'' gefolgt von ''n'' (für ''next''). Entfernt werden muss der Eintrag der MAC-Adresse.:
<!-- noch nicht er getestet -->
<!--  
'''Ab fedora 15''' ist zusätzlich noch der folgende Befehl nötig:
 
  rm -R /run/
-->


Bearbeite die Host abhängige Netzwerkkonfiguration und ändere den Hostname. Mit dem vorgeschlagenen Befehl öffnest du alle Netzwerkkonfigurationen auf einmal. Um mit vi zur nächsten Datei zu gelangen drückst du ''Esc'', gefolgt von '':n'' (für ''next''), gefolgt von ''Enter''. Entfernt werden muss der Eintrag der MAC-Adresse:


   vi /cluster/cdsl/?/etc/sysconfig/network
   vi /cluster/cdsl/?/etc/sysconfig/network
Line 201: Line 238:
   ln -s /proc/mounts mtab
   ln -s /proc/mounts mtab


Entfernen der Network-Konfiguration des Cluster:
Entfernen der Netzwerkkonfiguration des Cluster:


   rm -f /etc/sysconfig/network-scripts/ifcfg-eth0
   rm -f /etc/sysconfig/network-scripts/ifcfg-eth0


 
Anpassen von '/etc/fstab'. Es darf kein Root-Filesystem mehr eingetragen sein. Und ggf. auch kein swap mehr.:
Anpassen von '/mnt/newroot/etc/fstab'. Es darf kein rot-Filesystem mehr eingetragen sein.:


   devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
   devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
Line 230: Line 266:


   chkconfig NetworkManager off
   chkconfig NetworkManager off
Ab Fedora 16 mit ''systemd'':
  systemctl disable NetworkManager.service


=== Erstellen der boot-Konfiguration ===
=== Erstellen der boot-Konfiguration ===
    
    
 
Es muss eine PXE-boot-Konfiguration erstellt worden sein.  
Es muss eine PXE-boot-Konfiguration gemacht worden sein.  


==== TFTP Konfigurationsbeispiel ====
==== TFTP Konfigurationsbeispiel ====


Die TFTP Konfigurationkönnte etwa so aussehen...
Die TFTP Konfiguration könnte etwa so aussehen...


 
'''Beispiel A:''' Hier werden dem Cluster beim Booten die wichtigsten Informationen mitgegeben:
ExaBeispiel A. hier werden dem Cluster beim booten die wichtigsten Informationen mitgegeben.:


  # Menus
  # Menus
Line 255: Line 293:
   APPEND initrd=/nfsdracut/initrd_sr root=nfs:192.168.122.1:/mnt/virtual/nfsosr/fc11 rw rd.shell rd.debug
   APPEND initrd=/nfsdracut/initrd_sr root=nfs:192.168.122.1:/mnt/virtual/nfsosr/fc11 rw rd.shell rd.debug


 
'''Beispiel B:''' Hier eine Konfiguration die alle Information aus der Clusterkonfiguration zieht bzw. zur boot-Zeit automatisch generiert:
 
Beispiel B. Hier eine Konfiguration wo alle Information aus der Cluster-Konfiguration zieht bzw. zu boot-Zeit automatisch generiert:


  # Menus
  # Menus
Line 270: Line 306:
   KERNEL /OR-nfsdracut/vmlinuz
   KERNEL /OR-nfsdracut/vmlinuz
   APPEND initrd=/nfsdracut/initrd_sr  
   APPEND initrd=/nfsdracut/initrd_sr  


==== Erstellen des ''Shared Root initrd'' ====
==== Erstellen des ''Shared Root initrd'' ====


 
Auf dem Node, der zur Installation verwendet wurde und zu diesem Zeitpunkt immer noch im chroot-Modus sein sollte, wird jetzt das 'initrd' erstellt.
Auf dem Node, der zur installation verwendet wird und zu diesem Zeitpungt immer noch im chroot-Modus sein sollte, wird jetzt das initrd erstellt.
On installnode create the shared root initrd into the shared boot filesystem:


Für ein ''static initrd'' wird dieser Befehl ausgeführt:
Für ein ''static initrd'' wird dieser Befehl ausgeführt:
Line 283: Line 315:
   dracut -f -a "osr" /boot/initrd_sr-$(uname -r).img $(uname -r)
   dracut -f -a "osr" /boot/initrd_sr-$(uname -r).img $(uname -r)


Oder - wer alle features nutzen will benutzt:
Oder - wer alle features nutzen will verwendet den folgenden Befehl:


   dracut -f -a "osr osr-cluster" /boot/initrd_sr-$(uname -r).img $(uname -r)
   dracut -f -a "osr osr-cluster osr-chroot" /boot/initrd_sr-$(uname -r).img $(uname -r)
 
Das erstellte initrd und der Kernel muss jetzt noch in den TFTP bzw. PXE-Server kopiert werden, mit er für den Netzwerk-boot zur Verführung steht.


Das erstellte 'initrd' und der Kernel muss jetzt noch in den TFTP bzw. PXE-Server kopiert werden, damit diese für den Netzwerk-boot zur Verfügung steht.


=== Aufräumen ===
=== Aufräumen ===


Auf dem Node der (bisher) zum installieren verwendet wurde, wird nun der chroot-Modus verlassen und die Verzeichnisse ausgehangen:
Auf dem Node der (bisher) zum Installieren verwendet wurde, wird nun der chroot-Modus verlassen und folgende Verzeichnisse ausgehangen:


   exit
   exit
Line 303: Line 334:
=== Starten des zweiten Nodes ===
=== Starten des zweiten Nodes ===


Es ist eine sehr gute Idee, an dieser Stelle, den zweiten Node zu starten um zu sehen, ob die Konfiguration okay ist. Kommt es zu problemen, können siese mit dem ersten Node noch korrigiert werden.
Es ist eine sehr gute Idee, an dieser Stelle, den zweiten Node zu starten. Auf diese Weise ist zu sehen, ob die Konfiguration in Ordnung ist. Kommt es zu Problemen, können noch Korrekturen mit dem ersten Node gemacht werden. Dazu müssen die nötigen Verzeichnisse im ersten Node wieder eingehangen werden und ein chroot gemacht werden.
 
 


== Weiterführende Links ==
== Weiterführende Links ==
Line 313: Line 342:
* Git-Repository: [https://github.com/Open-Sharedroot/Open-Sharedroot-Dracut github.com]
* Git-Repository: [https://github.com/Open-Sharedroot/Open-Sharedroot-Dracut github.com]


 
== Kommentare und Diskussionen ==
 
== Kommentare und Diskusionen ==
* Siehe [[Talk:Features/Opensharedroot]]
* Siehe [[Talk:Features/Opensharedroot]]


== Quellen ==
== Quellen ==

Revision as of 12:44, 12 September 2011

Open Sharedroot

Einführung/Zusammenfassung

Das open sharedroot project dient dazu mehrere Linux-Systeme mit einem Root-File-System zu benutzen. Ins besondere Cluster-Systeme deren Nodes sich ein gemeinsames Root-File-System teilen. Der Sinn dahinter ist, das die Arbeit für die Syncronisierung der Nodes weg fällt. So teilen sich z.B. alle Nodes die Apache-Konfiguration. Wenn auf einem Node die Apache-Konfiguration geändert wird, muss diese Änderung nicht auf den anderen Nodes nachgezogen werden. Die Hostabhängigen-Dateien werden mittels CDSL eingehängt.

Folgende File-Systeme werden vom open sharedroot project unterstützt:

  • NFSv3, NFSv4
  • GFS2
  • Ocfs2
  • Ext3 als lokales Filesystem

open sharedroot cluster besteht aus drei Hauptkomponenten:

  1. Einem angepassten initrd (com.oonics-bootimage) um das System zu booten, da es einige Anpassungen braucht, um von einem Cluster-File-System booten zu können.
  2. Zum Teil angepasste Cluster-Dienste für die Cluster-Funktionalität. Diese Tools sind als com.oonics-Cluster Suite zusammengefasst..
  3. com.oonics-cdsls Ein Tool zum erstellen der cdsl Struktur (context dependent symbolic links). Das cdsl Konzept basiert auf bindmounts.

Getestete Distributionen

  • RHEL5
  • RHEL4
  • Fedora 11
  • Fedora 12
  • Fedora 14

Beispiel-Konfiguration/Installation

Übersicht

Es wird ein Fedora 14 als KVM-Wirt-System installiert. Dieser Wirt-Server dient auch als DHCP-Server und als TFTP-Server. Hier werden als zwei virtuelle Maschinen, (als zwei Nodes) installiert. Dies ist natürlich keine hochverfügbare Lösung, sondern dient nur dazu, das Grundprinzip zu demonstrieren ohne teure Hardware bereitstellen zu müssen. Würden die beiden Nodes auf eigener Hardware laufen und auf ein richtiges HA-Storage zugreifen, hätte man eine richtige HA-Lösung.

Wirt-System und Infrastruktur

Eine normale Fedora Installation mit KVM dient als Wirt-System. Standardmäßig ist KVM so konfiguriert dass alle Gastsysteme mit einer internen IP (192.168.122.*) via NAT nach draußen geroutet werden.

Auf dem Wirt-System sollten zwei virtuelle Gäste installiert werden. Jeder der beiden repräsentiert eine Node.

Vorbereitung NFS und PXE

Es müssen DHCP/TFTP/PXE so eingerichtet werden, dass die Nodes später damit booten können.

In der Datei /etc/exports wird das Verzeichnis eingetragen welches als NFS-Root-Filesystem dienen soll. Beispiel-Konfiguration:

/mnt/virtual/nfsosr/fc11  192.168.1.0/255.255.255.0(rw,no_root_squash,sync,fsid=208)

Mit die Änderung wirksam wird, muss der Server veranlasst werden, die Konfiguration neu ein zu lesen:

service nfs reload

Bei der PXE-Boot-Konfiguration ist noch einiges mehr zu beachten. Hier ist die einschlägige Dokumentation zu konsultieren.

Node Vorbereitung

Der Node von dem installiert werden soll, sollte mit einem Update auf den aktuellen Stand gebracht werden, bevor der Cluster aufgebaut wird:

yum update -y

Die Netzwerkunterstürzung von Dracut installieren:

yum install dracut-network

Installation der OSR-Pakete

Zunächst muss natürlich Dracut in der letzten Version installiert sein (Siehe: Dracut).

Die unterschiedliche Arten einen Cluster zu booten

Es gibt prinzipiell zwei Wege das Booten des Clusters zu steuern/konfigurieren.

  1. static initrd: Dem Bootloader können Parameter mitgegeben werden. Diese Parameter werden über den üblichen Weg gesetzt. Entweder über die Grub-Konfiguration oder beim Booten mittels Boot-Menü (hier edit-Modus).
  2. full featured initrd: Beim Erstellen des initrd über Dracut werden die Werte der Clusterkonfiguration ausgelesen und im initrd gespeichert, einschließlich Root-Device, Node-ID, MAC-Adresse usw.

Der erste Weg hat den Vorteil, dass das initrd nicht geändert werden muss wenn sich die Konfiguration des Cluster ändert. Der Vorteil des zweiten Weges ist, dass alle Features unterstützt werden die ein OSR-Cluster bietet. Zudem kann eine Boot-Konfiguration für alle Nodes benutzt werden.

Benötigte RPMs für static initrd

Führe folgenden Befehl aus:

 yum install osr-dracut-module comoonics-cdsl-py

Oder installiere folgende RPMs (aber jeweils letzte Version):

Benötigte RPMs für full featured initrd

Führe folgenden Befehl aus:

 yum install osr-dracut-module comoonics-cdsl-py osr-dracut-module-cluster

Oder installiere folgende RPMs (aber jeweils letzte Version):

Entwickler-Versionen installieren

Wenn du die neueste Entwicklerversion benutzen möchtest, verwende unser Git-Repository: github.com

Verfahre dazu wie folgt:

yum install git
git clone git://github.com/Open-Sharedroot/Open-Sharedroot-Dracut.git
cd Open-Sharedroot-Dracut

Für fedora 12:

git checkout -b fedora_15 origin/fedora_12

Für fedora 14:

git checkout -b fedora_15 origin/fedora_14

Für fedora 15:

git checkout -b fedora_15 origin/fedora_15

Und so weiter... Wer die letzte Entwicklerversion verwenden will, benutzt:

git checkout master
yum remove osr-dracut-module osr-dracut-module-cluster
git pull
make
make install

Um die Pakete wieder zu deinstallieren (wenn du das möchtest/musst):

make uninstall

Erstellen einer Cluster-Konfiguration

Erstelle eine Clusterkonfigurationsdatei im Pfad /etc/cluster/cluster.conf .

In der folgenden Beispielkonfiguration fehlen die 'valid fencing' Konfigurationen. Das ist natürlich später ein mal wichtig, wenn der Cluster produktiv arbeitet soll.

   <?xml version="1.0"?>
   <cluster config_version="1" name="axqad109" type="gfs">
    <clusternodes>
            <clusternode name="node1" nodeid="1" votes="1">
                    <com_info>
                            <rootvolume fstype="nfs" name="192.168.122.1:/mnt/virtual/nfsosr/fc11"/>
                            <eth name="eth0" ip="192.168.122.171" mac="00:0C:29:C9:C6:F5" mask="255.255.255.0" gateway="192.168.122.1"/>
                    </com_info>
            </clusternode>
            <clusternode name="node2" nodeid="2" votes="2">
                    <com_info>
                            <rootvolume fstype="nfs" name="192.168.122.1:/mnt/virtual/nfsosr/fc11"/>
                            <eth name="eth0" ip="192.168.122.172" mac="00:0C:29:C9:C6:F5" mask="255.255.255.0" gateway="192.168.122.1"/>
                    </com_info>
            </clusternode>
    </clusternodes>
   </cluster>

Erstellen eines shared root filesystem

Das shared root filesystem muss von einem NFS exportiert werden, damit es zur Verfügung steht. Dann kann auf dem Node der für die Installation dient das NFS eingehangen werden. Mit diesem Befehl hängen wir das '/mnt/virtual/nfsosr/fc11' als künftiges Root ein.:

 mkdir /mnt/newroot/  
 mount -t nfs 192.168.122.1:/mnt/virtual/nfsosr/fc11 /mnt/newroot/  

Ab NFS 3 wird man wohl das Flag -o nolock nötig sein.

 mount -o nolock -t nfs  192.168.122.1:/mnt/virtual/nfsosr/fc11 /mnt/newroot/ 

Jetzt alle Daten des lokalen Systems in das (künftige) shared root filesystem kopieren:

 cp -ax / /mnt/newroot/
 cp /boot/*$(uname -r)* /mnt/newroot/boot

Dann müssen wir noch ein paar benötigte Verzeichnisse erstellen (wenn es sie noch nicht gibt):

 mkdir /mnt/newroot/proc
 mkdir /mnt/newroot/sys

Nun wird die neue cdsl-Infrastruktur auf dem shared root filesystem angelegt:

 com-mkcdslinfrastructure -r /mnt/newroot

Diese wird in das Filesystem eingehangen:

 mount --bind /mnt/newroot/cluster/cdsl/1/ /mnt/newroot/cdsl.local/

Dann werden weiter Verzeichnisabhängigkeiten dazu gemountet:

 mount -t proc proc /mnt/newroot/proc
 mount -t sysfs none /mnt/newroot/sys
 mount --bind /mnt/newroot/dev /mnt/newroot/dev
 

Jetzt wird in das neue shared root filesystem gewechselt und als root verwendet:

 chroot /mnt/newroot

Das '/var' Verzeichnis wird hostdependent (hostabhängig) gemacht (Parameter -a):

 com-mkcdsl -a /var 
 

Das '/var/lib' Verzeichnis wird wieder als shared(geteilt) eingerichtet (Parameter -s):

 com-mkcdsl -s /var/lib

Das '/etc/sysconfig/network' wird wiederum hostdependent gemacht:

 com-mkcdsl -a /etc/sysconfig/network


Bearbeite die Host abhängige Netzwerkkonfiguration und ändere den Hostname. Mit dem vorgeschlagenen Befehl öffnest du alle Netzwerkkonfigurationen auf einmal. Um mit vi zur nächsten Datei zu gelangen drückst du Esc, gefolgt von :n (für next), gefolgt von Enter. Entfernt werden muss der Eintrag der MAC-Adresse:

 vi /cluster/cdsl/?/etc/sysconfig/network

Erstellen des '/etc/mtab' link zu '/proc/mounts':

 cd /etc/
 rm -f mtab
 ln -s /proc/mounts mtab

Entfernen der Netzwerkkonfiguration des Cluster:

 rm -f /etc/sysconfig/network-scripts/ifcfg-eth0

Anpassen von '/etc/fstab'. Es darf kein Root-Filesystem mehr eingetragen sein. Und ggf. auch kein swap mehr.:

 devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
 tmpfs                   /dev/shm                tmpfs   defaults        0 0
 proc                    /proc                   proc    defaults        0 0
 sysfs                   /sys                    sysfs   defaults        0 0

Ausschalten von SELinux:

 [root@install-node3 comoonics]# cat /etc/sysconfig/selinux 
 # This file controls the state of SELinux on the system.
 # SELINUX= can take one of these three values:
 #       enforcing - SELinux security policy is enforced.
 #       permissive - SELinux prints warnings instead of enforcing.
 #       disabled - No SELinux policy is loaded.
 SELINUX=disabled
 # SELINUXTYPE= can take one of these two values:
 #       targeted - Targeted processes are protected,
 #       mls - Multi Level Security protection.
 SELINUXTYPE=targeted

Ausschalten des NetworkManager:

 chkconfig NetworkManager off

Ab Fedora 16 mit systemd:

 systemctl disable NetworkManager.service

Erstellen der boot-Konfiguration

Es muss eine PXE-boot-Konfiguration erstellt worden sein.

TFTP Konfigurationsbeispiel

Die TFTP Konfiguration könnte etwa so aussehen...

Beispiel A: Hier werden dem Cluster beim Booten die wichtigsten Informationen mitgegeben:

# Menus
# for OSR based on NFS

timeout 100
prompt 1
default NFS-dracut-Cluster

LABEL NFS-dracut-Cluster
  MENU LABEL NFSdracut NFS Configuration
  KERNEL /OR-nfsdracut/vmlinuz
  APPEND initrd=/nfsdracut/initrd_sr root=nfs:192.168.122.1:/mnt/virtual/nfsosr/fc11 rw rd.shell rd.debug

Beispiel B: Hier eine Konfiguration die alle Information aus der Clusterkonfiguration zieht bzw. zur boot-Zeit automatisch generiert:

# Menus
# for OSR based on NFS

timeout 100
prompt 1
default NFS-dracut-Cluster

LABEL NFS-dracut-Cluster
  MENU LABEL NFSdracut NFS Configuration
  KERNEL /OR-nfsdracut/vmlinuz
  APPEND initrd=/nfsdracut/initrd_sr 

Erstellen des Shared Root initrd

Auf dem Node, der zur Installation verwendet wurde und zu diesem Zeitpunkt immer noch im chroot-Modus sein sollte, wird jetzt das 'initrd' erstellt.

Für ein static initrd wird dieser Befehl ausgeführt:

 dracut -f -a "osr" /boot/initrd_sr-$(uname -r).img $(uname -r)

Oder - wer alle features nutzen will verwendet den folgenden Befehl:

 dracut -f -a "osr osr-cluster osr-chroot" /boot/initrd_sr-$(uname -r).img $(uname -r)

Das erstellte 'initrd' und der Kernel muss jetzt noch in den TFTP bzw. PXE-Server kopiert werden, damit diese für den Netzwerk-boot zur Verfügung steht.

Aufräumen

Auf dem Node der (bisher) zum Installieren verwendet wurde, wird nun der chroot-Modus verlassen und folgende Verzeichnisse ausgehangen:

 exit
 umount /mnt/newroot/cdsl.local
 umount /mnt/newroot/dev
 umount /mnt/newroot/proc
 umount /mnt/newroot/sys
 umount /mnt/newroot

Starten des zweiten Nodes

Es ist eine sehr gute Idee, an dieser Stelle, den zweiten Node zu starten. Auf diese Weise ist zu sehen, ob die Konfiguration in Ordnung ist. Kommt es zu Problemen, können noch Korrekturen mit dem ersten Node gemacht werden. Dazu müssen die nötigen Verzeichnisse im ersten Node wieder eingehangen werden und ein chroot gemacht werden.

Weiterführende Links

Kommentare und Diskussionen

Quellen