From Fedora Project Wiki

< Features‎ | Opensharedroot

Revision as of 13:25, 7 July 2011 by Radicke (talk | contribs) (fehler beseitigt)

Open Sharedroot

Einführung/Zusammenfassung

Das open sharedroot project dient dazu mehrere Linux-Systeme mit einem root-File-System zu benutzen. In 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 Host-Abhängigen-Dateien werden mittels CDSL eingehangen.


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

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

open sharedroot cluster besteht aus drei Hauptkomponenten:


  1. 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.
  2. Zum Teil angepasste Cluster-Dienste für die Cluster-Funktionalität. Diese Tools sind als comoonics-clustersuite zusammengefasst..
  3. comoonics-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 Machienen, (als zwei Nodes) installiert. Diese ist natürlich kein hochverfügbare Lösung, sondern dient nur dazu, das Grundprinzip zu demonstrieren ohne teure Hardware haben zu müssen. Wenn die beiden Nodes auf eigener Hartware laufen und auf ein richtiges HA-Storage zugreifen, hätte man eine richtige HA-Lösung.

Wirt-System und Infrastruktur

  1. Ein Fedora 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.

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


Vorbereitung

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

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 Cluster-Konfiguration 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, dss alle features unterstützt werden die ein OSR-Cluster bietet. Zudem kann ein 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

Or

Oder installiere folgende rRPMs (aber jeweils letzte Version):

Entwickler-Versionen installieren

Wenn du die neueste Entwickler-Version 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
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 ein Cluster-Konfigurations-Datei 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. 

   <?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 - natürlich - 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.: 

 mount -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 File-System 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 hostdependent network-Konfiguration und ändere den hostname. Mit dem vorgeschlagenen Befehl öffnest du alle Netzwerk-Konfigurationen auf ein mal. Um mit vi zu nächsten Datei zur gelangen drückst du Esc gefolgt von n (für next). 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 Network-Konfiguration des Cluster: 

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


Anpassen von '/mnt/newroot/etc/fstab'. Es darf kein root-Filesystem mehr eingetragen sein.: 

 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

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 Cluster-Konfiguration zieht bzw. zu 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 wird und zu diesem Zeitpungt 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" /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ührung 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 okay ist. Kommt es zu Problemen, können noch Korrekturen mit dem ersten Node gemacht werden. Dazu muss die nötigen Verzeichnisse im ersten Node wieder eingehangen werden und ein chroot gemacht werden.


Weiterführende Links


Kommentare und Diskusionen


Quellen



Retrieved from "https://fedoraproject.org/w/index.php?title=Features/Opensharedroot/de&oldid=244563"